It doesn’t matter how good your engineering team is if they are not given something worthwhile to build. Engineers do not thrive when given a meaningless list of features to build. They need to be included in the entire process – from planning, to product thinking, to implementation. You want your engineers to be collaborating and coming up with ideas. This is how you build a product minded org.
Everything starts with ideas. Usually, these ideas get shoved into a roadmap. Roadmaps, typically, go wrong for 2 reasons.
Here’s the thing. Nobody, nobody can know if a feature will succeed without context. Planning a roadmap too far out without is destined to fail because products are destined to fail. There is a process to discovering (product discovery) what products should be built, and failing to do discovery while sticking to a “roadmap” of what are essentially just guesses is going to lead to failure. The second point, on timing, is wrong because it takes time to build great products. There is an interative cycle of refining a great product, and so it becomes impossible to truly plan a roadmap. Else you are rushing.
This waterfall of ideas -> design -> implementation fails because the top of the funnel, the idea chamber, is not giving adaquate time to testing the ideas. Business leaders might think they have the best and the right ideas, but nothing matters unless you are talking to your customers.
A vast majority of roadmaps are essentially prioritized lists of features and projects. Two inconvenient truths of product.
projects are output and product is all about outcome. Yes, something was finally released, but it doesn’t meet its objectives so what really was the point?
Working the old way is more akin to product ownership. You “own” the product after is has been scoped, but you don’t really have much say. A PM in this old model is more akin to a scrum master or a project manager.
Ok, so roadmaps suck. What do we do about it?
Tackle risk up front. Don’t just come up with ideas and shoot them into the dark. Make sure the cover the big 4. a. value risk (the most important) - is this feature valuable to our customers. How do we know? b. feasibility risk - is this technically feasible in a reasonable amount of time? c. usability risk - is this feature usable (well designed)? d. viability risk - is there a business case for this feature?
Features are determined collaboratively. In strong teams, product, design, and engineering work side by side, in a give-and-take way, to come up with technology-powered solutions that our customers love and that work for our business.
Frame roadmapping as determining problems to solve, not features to implement. Conventional roadmaps are about output. How much are we accomplishing? None of this matters if we are not measuring impact instead. We want to measure business results.
We need to discover the product to be built, and we need to deliver that product to the market. Typically these things are ongoing and in parallel. We are always working in parallel to both discover the necessary product to be built—which is primarily what the product manager and designer work on every day—while the engineers work to deliver production-quality product.
While in discovery, we are tackling the risks before we even write code. The purpose is to separate the good ideas from the bad. While in discovery, we want to answer 4 questions.
Typically, we do product discovery by testing prototypes. Delivery is the process of actually implementing the features, sort of self explainatory.
This refers to the longer-term objective of this product, normally 2–10 years out. The entire roadmap should roll up into tasks that are accomplishing the company’s product vision.
In a good product team, everyone on the team (PM, Design, Engineering) is contributing to determining what to build. Not only does this increase the amount of good ideas, but it increases buy in from everyone on the team. You let people hold themselves accountable to what they are building, and let them get excited about the solutions they are coming up with to solve the business problems. (Do we trust everyone? Thats a common complaint. But I am the product person, I have the ideas) boo hoo to you. A big part of the concept of product teams is that they are there to solve hard problems for the business. They are given clear objectives, and they own the delivery of these objectives. Instead of just building what others determine might be valuable, in the product team model the full team understands — needs to understand — the business objectives and context. And most important, the full team feels ownership and responsibility for the outcome. Instead of the old project-oriented model, which is all about getting something pushed through the process and out the door, in the dedicated team model, the team is not off the hook just because something launches. They don’t rest until and unless it’s working for the users and for the business.
Evaluating opportunities and determining what gets built. The hard part is determining that what gets built is worth building, as shown be evidence from customer interviews or other validation techniques.
The product manager should share and document their learnings with the team, because ultimately it helps everyone to understand all of these things. The PM should just be the expert.
Rather than being measured on the output of their design work, the product designer is measured on the success of the product.Designers further understand that the user experience is as important to customer value as is the underlying functionality. Designers are communicating to the engineers what constraints exist around the problem. Good product designers use prototypes as their primary canvas for communicating ideas, both internally and externally. They are generally comfortable with many different prototyping tools and are able to apply the correct one for the task at hand. Good designers are constantly doing user testing.
One of the key themes of this book is focusing on outcome and not output. Realize that typical product roadmaps are all about output. Yet, good teams are asked to deliver business results. Weak teams just plod through the roadmap they’ve been assigned, month after month. The two inconvienent truths would tell you this is a bad idea. There is no validation when you are just plucking tasks off of a roadmap. Key word: validation
product discovery as the most important core competency of a product organization. Good teams will do product discovery ahead of roadmap to ensure that the roadmap is outcome driven. Solve the underlying problem, not just develop a feature. Roadmap should be a list of problems we want to address, and thats it. Sprints scope the work around those problems and tackle the work head on.
If we can prototype and test ideas with users, customers, engineers, and business stakeholders in hours and days—rather than in weeks and months—it changes the dynamics, and most important, the results.
Realize that developing great people requires a different set of skills than developing great products. How do you develop great people?
17 Mar 2021