We’re currently on week 14 of Agave, and I wanted to write a little about the product development process inside my brain as Jared and I are working on building the best virtual office in the world for remote teams to have serendipitous interactions.
Separate problems/opportunities and solutions
It’s such a common mistake to make – mixing up problems and solutions when trying to decide what to include in a given sprint. Every team has a Kanban board, a 2×2 matrix, or a backlog with both problems and solutions all mixed together. A simple example might be “onboarding is too complicated” – this is a problem. “Build lifecycle emails” is a solution to a problem.
The best product processes I’ve ever seen place a strict separation between these two things, and treat them differently. Problems should be stack-ranked in terms of importance or impact. What problems are we solving? In what order? This week, are we focused on fixing acquisition problems? Engagement problems? Churn problems?
Problems can and should be debated vigorously. Lock horns, butt heads, exercise those strong opinions and subject matter expertise. Bring data to back up your statements. Argue. Foster internal competition on what the problems are, and in what order we should solve them.
Ideally, at some point you draw a line between the need-to-solve problems and nice-to-solve problems. (And then throw out the nice-to-solve problems, you’ll never get to them.)
Solutions are different. They require a completely different frame of mind. Once you’ve got your stack-ranked problems, conduct a brainstorming session – “yes, and” instead of “yes, but”. It’s not about debating which solution is best – it’s about getting as many ideas out onto the table as possible. Cultivate ideas from every part of the company – at this stage, no idea is a bad idea. You want a ton of fodder for the next step.
This is a great time to think hard about what competitive advantages your team has. How can you use your superpowers to solve these problems in ways other teams cannot?
After you’ve got your whiteboard full of ideas to solve a particular problem, you should be able to identify similarities amongst some of them – ideas that are sort of adjacent to one another or have lots of overlap. Identify these adjacencies – combine these ideas and, if necessary, refine some of them to be a little more detailed or fleshed out. Don’t go overboard – just be able to describe them in a sentence or two.
(Optional): Deep-dive on each solution
If you have the time and resources, it’s sometimes worth taking some time to get smarter about the actual cost and benefit of each solution. Figure out who the target user is for each solution, what are the substitutes / complements for this solution, what are the success metrics or go-to-market details, and then sketch out the MVP solution, effort, and implementation. Identify risks, assumptions, stakeholders, and dependencies in your organization.
Not all teams can and should perform this step, but if you can, you’ll be much more well-equipped for the next step.
Effort and Impact
Now is the time to finally bring those ideas to your 2×2 matrix. For each problem you need to solve, take the ideas for that problem and throw them onto the board. Like this:
This can (and should?) be a little messy. Just toss them on there somewhere and discuss their position on the board with your teammates. The people on the team thinking most about the business goals can have more of a say in the impact axis, while the people responsible for implementing the ideas can have more influence in the effort axis.
You’ve got your roadmap
That’s basically it. Once you’ve got your team in rough agreement on the cost-benefit impact-effort of the ideas to solve a particular problem, you can literally work your way from top-left to bottom-right. There’s your stack rank.
Other stuff
This does not need to take a long time. For super small teams of 4 or less this can take an hour: 5 minutes for problem identification, 5 for stack ranking, 15 or 20 for brainstorming, and the rest for impact/effort discussion. For larger teams it can span a week or more.
If you follow this process week-by-week, month-by-month, quarter-by-quarter for a long time, you can sometimes find yourself not working on anything “big”. This is a common criticism that I intend to write about elsewhere. Suffice it to say, you should adjust this process to suit your needs. Many teams take a sprint here and there to switch gears completely away from this approach and perform rapid prototyping or hack-weeks to showcase what they think could leapfrog the current product. This is a great example of The Innovators Dilemma.
This process lets all participants have a say. The people closer to the customers bring valuable data and instincts about what customers want. The designers and engineers bring valuable opinions about what’s possible. The sales and marketing pros bring valuable intel about what the market is telling your company. Customer support reps bring valuable data about what customers are having trouble with. All of these people have valuable data and insights that can and should influence your company’s product roadmap.
(And if you don’t want your people participating in this process, why did you hire them in the first place?)
It can be hard to do but I’ve found it to be an invaluable component of building a world-class team.
