“If you can’t describe what you are doing as a process, you don’t know what you’re doing.”
W. Edwards Deming
In my 11 years in product management, I’ve worked with product teams at companies large and small. Regardless of size, many of those teams don’t have a well-defined process that helps product managers answer the question “how do we know we’re building the right thing?”
Google “product management process” and you’ll find a hodgepodge of results ranging from awkward visuals and guides on writing tech requirements to multi-step stages that highlight solutions over discovery work. It’s no wonder product management is so often misunderstood.
Without deliberate implementation of a product process that works, most teams gravitate towards one of the extreme ends on spectrum ranging from rigid to loose.
In a rigid process, decisions are made top down. Priorities are determined by a small group of people with fancy titles or the loudest person in the room. In a loose process, decisions are made on the fly. Typically the newest or shiniest ideas are given priority.
As you can imagine, there are major issues with both.
With the rigid approach, the company is relying on a select group of people to do all of the ideation. Priority is typically placed on large projects that take a long time to build and rarely meet goals. Product managers working for companies who adhere to a rigid approach will feel like they’re nothing more than order takers and turnover will be high.
The loose approach might work for a while, especially for young startups who are scrambling to achieve product market fit, but once a company reaches the growth stage the lack of direction will lead to chaos, dropped balls and miscommunication. Product managers working with loose processes will feel like their contributions are insignificant and can easily experience burn out.
If you find your team operating on one of these extremes, I suggest trying something different.
Luckily there is an alternative that helps focus the team on outcomes for users and the business, motivates people to do their best work, and is flexible enough to change direction if necessary.
Before I speak to that, I’m going to assume that your company is already empowering your product managers to solve interesting problems. That means giving them autonomy, support and the resources needed to do what they think is best for the business, your users and the market. Marty Cagan speaks to this much better than I ever could in his insights blog. If that’s not already happening, then unfortunately no framework or reworking of processes will help.
If product managers have been empowered then reframing how you look at product processes might be all you need to ensure that you’re continuously innovating, improving key metrics and keeping your users happy.
So what’s an alternative that works? It’s rather simple and involves four key stages: Vision > Strategy > Objectives > Execution. There’s a tendency for teams to race immediately to the Execution stage, but it’s impossible to know where you’re going without giving the necessary attention to each stage before it.
Vision
It starts with a product vision. Too many teams skip this step because they want to jump right into development. If you do that, you’ll end up wasting a lot more time down the road realigning the team.
The vision sets the foundation for the product org and serves as a guidepost for the entire product lifecycle. Not to be confused with the company mission statement, the product vision describes what you hope to achieve with the product long term.
It is meant to inspire almost everyone who touches the product — the product team, stakeholders, leadership, investors, and even some users.
A strong product vision ensures everyone is working towards a clear, inspirational and actionable objective that solves a user problem.
“If you define the problem correctly, you almost have the solution.”
Steve Jobs
Strategy
If the vision is where you want to be, the strategy is the path you plan on taking to get there.
A good product strategy will help determine the following…
- Markets/Personas – what users should we prioritize first, second, third?
- Problems – what needs are we solving for our personas?
- Value proposition – what are our key differentiators and how can we highlight or improve that?
Right about here is where we’d typically find a product roadmap, a document that plots all features the team will work on for the next 6-12 months.
The problem with that is no one can possibly know what will be best for users in 1 month let alone in 6 or 12 months.
Roadmaps allow for only a few big projects and many potentially great ideas get killed off immediately. It’s important for teams to remain agile and constantly learning. If you’re not careful, a roadmap can be detrimental to that. They serve the purpose of communicating to stakeholders fabulously. It’s easy to communicate a narrative around a linear path dedicated to outputs. We’ll build x first, then y, then z.
But isn’t the goal to deliver successful outcomes for the business and users?
Amin Bashi, of Crowdriff puts it nicely,
“It’s easy to see features as a numbers game: more features leads to more adoption and therefore more revenue. The hard truth is that there is barely any correlation between the total number of features offered and product adoption — successful features are what matter. That means finding the features that really matter to your customers and focus on delivering those. To do that requires flexibility. The last thing you need is to lock yourself into a roadmap.”
Amin Bashi, Crowdriff
So what’s the alternative?
I’m glad you asked.
I think one of the best alternatives to a traditional roadmap is Itamar Gilad’s GIST format. It’s strength lies in a roadmap’s weakness — flexibility.
Using this model product teams are responsible for outcomes, not outputs. Product discovery can be sped up to ensure you’re not building bloated features and instead focusing on impact.
If you’re interested in this “roadmap killer,” please check out Itamar’s article. He’s much more articulate at explaining it than I will ever be.
Objectives (Goals)
Ok so we have our vision and strategy. Let’s begin building, right? Not so fast. I’m a huge proponent of moving fast, but you’d be blindly throwing darts without first determining how you’re going to measure success.
There are many directions companies go here, but the most important part is having a consistent framework. Objectives, like the vision, should be ambitious, measurable and achievable.
I personally like the OKR framework, which stands for Objectives and Key Results. The objectives should be a qualitative statement that is actionable (usually within a quarter). The key results are quantitative metrics that are usually incredibly ambitious but achievable.
If done right, it will greatly help the team towards building the right thing and reducing waste.
Quick word of caution here — a lot can go wrong with any goal setting, OKRs included. Read up on common pitfalls and make sure you’re using the framework properly.
Execution
“We all want progress, but if you’re on the wrong road, progress means doing an about-turn and walking back to the right road; in that case, the man who turns back soonest is the most progressive.”
CS Lewis
At this point the product team understands the vision, strategy and business objectives. It’s now up to them to solve problems for our users (personas) and create amazing products that achieve our objectives.
This is where product managers and designers will begin day to day product discovery. Part of that might be collecting and documenting ideas, which can come from anywhere (product team, users, other departments, C-suite, etc.), prioritizing those ideas using one of the dozens of prioritization methods (RICE, MoSCoW, Value vs. Effort, Kano, etc.) and testing as many as possible.
Example from my case study on Airbnb.
Once we have data on how well our tests performed we can begin development.
There should be a never ending cycle of generating ideas, testing ideas, analyzing the results and actual development.
A step that many teams miss is they forget to analyze features after they’re already built. Since we’re always looking forward to the future, it’s sometimes difficult to look back at how well features actually performed. This is a critical step for two reasons. First, it’s impossible to judge a feature’s future impact without analyzing how past features performed in the real world. Second, this is how we learn what does and doesn’t work and how to improve with future features.
Conclusion
Whether we’re talking about an industry leader or a startup hoping to gain traction, creating a strong product process is critical for success. Some teams can get away with operating without a set vision, strategy or objectives, but it won’t be long before chaos ensues.
Product process should never be so rigid that it strangles creativity and flexibility or so loose that the team struggles to understand where they’re going long term. If a team is empowered to solve difficult problems and supported by a strong product process, I think you’ll be surprised with what they come up with.
The four tier product process is a decent place to start.