Get Your Product Back On Track

Using a Product Council can improve visibility and predictability

One of the biggest challenges in scaling a company comes when the Engineering and Product functions expand beyond the founders. What started out as a tight-knit effort between a small, high-functioning group turns into any number of problems:

• Feature creep

• Blown schedules

• Projects in limbo that never ship

• Teams get larger but fewer things make it out the door

• Major unplanned rework of features, user interface or architecture

• Corners are cut in QA or performance testing

• Overtime evenings and weekends in crunch mode

• Engineering burnout, low morale

• Marketing is surprised to learn that several key features got cut

• Sales doesn’t know how to sell it

• Product features don’t land with customers

Over the years, I’ve seen all these issues and more. While it’s tempting to blame the outcome on the head of Engineering (whose head must surely roll), changing out the leadership without changing the process is likely to yield only an incremental improvement.

If you’ve suffered from some of the problems, you might break into a cold sweat thinking about past situations. But rest assured, it doesn’t have to be that way.

In several companies, I have helped implement a Product Council and review process that can provide better visibility and predictability as well as a standardized process that addresses many of the problems above. It’s not a panacea, but it can make things run much smoother. Software development is part art and part science. This requires a balance of exploration and constraints.

You’re also trying to create an environment where Engineering is going to take on some risky projects and if they don’t succeed, you redirect or shut down the efforts quickly and without a huge stigma.

The development activities of any given Engineering team or squad is determined by the Product Manager and Engineering Manager working together. They are the leaders of the team, and if the team is failing or wildly successful, it ultimately reflects this leadership. The features under development should fit into the overall priorities of the company, the roadmap, competitive situation, customer feedback, etc. The team, represented by the leadership of Product and Engineering, should be building features and improvements that are measurably improving the company’s business outcomes and the customer experience. If they are not, you need to redirect and change tactics to get better results in the next cycle.

The Product Council is built on several fundamental ideas:

• The job of the Product Council is to periodically review an Engineering team’s progress toward defined objectives. Typically, I have found that a 90 day window works well, with a kick-off at the beginning of the quarter, a mid-point check-in and an end-of-quarter review.

• The Product Council should include the head of Product, the head of Engineering as well as representation from Marketing, Sales, Customer Success. Key leaders (or proxies in their stead) represent the core functions of the business. This ensures every department is in sync and aware of what is being built and why.

• The Product Manager and Engineering Manager together present their team’s plans to the Product Council for review and approval. They can also ask for guidance, input, more resources, etc. The EM and PM must work together at all times. There can be no finger-pointing.

• The council membership (the key leaders of various functions) must provide guidance, ask for more detail, approve, redirect or cancel any product development when it is under review.

A Product Council meeting typically runs 45 minutes. Materials and artifacts are shared ahead of time and it’s expected that the product council membership reads these materials in advance. It’s usually a good idea for the EM and PM to walk through the material with the VP of Engineering and/or the VP of Product in advance to identify areas that need more customer research, more data, and so on. Doing a “dry run” helps avoid surprises and can often improve the session for all attendees with more strategic insight, clearer communication, identification of risks or potential problems.

The EM and PM should present a plan that identifies what they propose the team works on for the next cycle (typically 90 days). This should encapsulate why the work is being done, what the technical risks are, plans for mitigating the risk, what a successful outcome looks like and how it will be measured. For example, if customers are complaining about the speed of the product, there should be a clear proposal for how the problem will be solved, and the resulting performance gain they are aiming for. If there are competitive features being addressed, how will the new features be better than the competition? If there is technical debt to be corrected, how will it improve customer experience or reduce the support burden?

This is not a meeting in which the product council members are meant to sit back and throw rocks at a squad. As I often told the PMs and EMs, it’s not a PhD thesis defense. The Product Council is there to contribute and help the team.

Avoid Surprises

A key element in reviewing the product plan in the Product Council is to make sure that Marketing and Sales are bought in and hopefully see some major new capabilities that will expand the market or reduce sales obstacles. If Marketing and Sales don’t see major headline features, that should be considered a red flag. At the very least, it might suggest revisiting the marketing launch efforts. It’s always better to find out early in the process when something can still be done, changed, or strategy shifted rather than when the product pages go live.

The mid-quarter check-in meeting is done in order to verify progress is being made and also to consider taking more drastic action for any items that are not going as planned.

I first used the Product Council process way back in the day at Borland. It helped us get several key projects on track, sometimes by cutting back features. I’ve used a modified version of this in other companies from time to time. At Gatsby, Dustin Schau, then VP of Product rolled out the Product Council to provide much needed focus and discipline. While it placed an added burden with a cluster of meetings (one for each squad) it made our Engineering and Product delivery process far more predictable and aligned across Product, Engineering, Marketing, and Sales As Dustin sometimes would say, if we’re going to have a meeting, we’re going to make it valuable, and Product Council certainly was a valuable meeting for all functions.

Find and Fix Problems Early

As an example from Gatsby, in a mid-quarter check-in we learned that an experimental feature we had dubbed “Luda Mode” didn’t reliably deliver the 10x performance gains the team had planned when testing with customers. Rather than treat this as a failure, the team took feedback from the Product council session and identified and delivered other performance gains that, while not quite 10x, delivered a marked improvement to the customer experience and one that Sales and Marketing could still trumpet with minor changes. This is a good example of embracing a “failure,” learning what can be done, and using the mechanism to communicate and discuss openly the right, customer-focused strategy. Best of all, everyone was in sync.

By now, you get the idea. Product council exists to drive alignment, awareness, and strategy down to the squad (where it belongs!), upwards to the Product Council, and across all key functions of the business. It can be an effective process to make Engineering more predictable and increase confidence that you are building the right products. Note also, that the Product Council is not a substitute for the normal day-to-day and weekly management of Product and Engineering.

The Product Council works well at high-growth startups, and can be applied equally well in larger organizations to help increase collaboration between Product and Engineering. It also helps reduce the number of surprises when launching products. Try some of the ideas out, make them your own adapting to your unique situation. And let me know how it works, by posting a comment below.

If you’ve found these ideas helpful, I hope you’ll share them with your team.