Collection of wisdom from other people.
- No split of ideation, planning and execution — they all happen concurrently all the time
- Goals rather than solutions or vague strategy statements.
- Idea banks rather than product backlogs.
- Short sub-quarter step-projects rather than long multi-quarter/multi-year projects.
- No betting on just a few big ideas that take forever to implement — we test many ideas quickly and pursue the ones that work.
- Iterations — we revisit every part of the plan regularly and systematically and stay agile at all levels.
In the time it took to decide between which of the two features to build, they could have built both and gained insights from customers about what will achieve the best results.
We as a startup can't let roadmap process take too much time from actually building the product.
Have a vision: A north star that you may never reach, and make sure that north star is based on a validated customer need. The products and features you build to realize that vision may change, but the vision itself will not change.
What is our north star aka product vision?
You must incorporate input from a number of different sources. These sources include:
- Customer feedback
- Engineering
- Sales and marketing
- The c-suite
- Partners
- Company vision
- Company business objectives
- Company and product strategy
Rather than try to predict what features they will build years into the future, agile product managers regularly update their roadmap based on emerging market opportunities and customer feedback.
Make your roadmap simple and easy to understand. Communicate the most important elements of your strategy, goals, and development milestones, and leave out the rest. The details are likely to evolve as you get feedback from customers, anyways.
Present the roadmap to all stakeholders. Internal stakeholders include engineers, product managers, the c-suite, and sales and marketing teams. Each stakeholder will want different information, so you’ll need to adapt your message accordingly.
- Roadmap = set of decisions
- Good decisions are made by first knowing your inputs
Inputs:
- Company goals – OKRs
- Product vision
- Business Model – feature that many small customers want vs feature that one big customer wants
- Feedback channels – For each channel specify source, qual/quant, useful for, watch out for, cost (time), weighting
Teams that fall in love with a problem have more successful outcomes than teams that fall in love with particular solutions. This is because knowing that a problem is worth solving continues to be motivating even when a team doesn’t come across the right solution on the first, second, or Nth try.
Goal driven prioritization:
- Give team a metric
- A good metric – understandable, comparative, ratio/rate, behaviour changing Lean Analytics Book
- Avoid trial-and-error approach by defining counter metrics
- Give team a problem
- Highly motivating if your team understands the value
The reality is that stakeholders clouding decisions without evidence can derail even the most well thought-out plans. Nobody likes it when high-level ideas are added to the roadmap as must-haves, especially when they are not backed up with validation.
Prioritization can be polarizing because it’s often perceived as choosing one person’s ideas over another’s. When people have something personal invested in an idea or feature that’s on the chopping block, emotions can run high. The solution is collaborating at several levels. It is the product leader’s job to connect with all the stakeholders and communicate to each of them why certain choices have to be made. It starts with developing a shared vision and purpose for the product.
If the team doesn’t agree on the big picture, then they certainly won’t agree on a single feature.
Summary of Prioritization Considerations:
- Prioritization is Personal: Don’t overlook the subjective attachments and emotional value of choosing features.
- Executive Button: Senior leaders, investors, stakeholders and executives have something meaningful to add. However, whenever possible make sure this input is supported by context and data.
- Proof Points: Seek methods to shore up your data and research with evidence about what is valuable and what is not. Priorities are easier to filter when you have the facts.
- Collaboration, Not Consensus: Get input from all the interested or invested parties, but not at the expense of progress.
- Rooting Vision To Practice: Ensure your company or product vision remains at the forefront of all prioritization conversations.
- How Not to Prioritize: Gut reactions, isolated sales and support requests, analyst opinions, and out-of-context unit economics are relevant but not critical to prioritization.
- Prioritize With Purpose: Feasibility, desirability and viability are the product leaders core principles. Use these guides to help filter and prioritize.
- Constraint Methodology: Use a finely-tuned process to help filter the work ahead. Constraints are powerful lens to focus outcomes.
- Visual Clues: All journeys require a map. Use themed roadmaps to clarify the steps ahead and remind team members where you’re headed.
Our roadmap is planned out roughly 3 – 6 months ahead at all times. So as we add things to the roadmap and reassess existing items, we also keep a giant backlog of everything else. This is all the other ideas we have that are not on our roadmap. ... As you move forward things change, and so there will be items on your backlog that rightfully stay there forever.
For any given feature with limited adoption, you have 4 choices:
- Kill it: admit defeat, and start to remove it from your product
- Increase the adoption rate: Get more people to use it
- Increase the frequency: Get people to use it more often
- Deliberately improve it: Make it quantifiably better for those who use it
RICE is an acronym for the four factors we use to evaluate each project idea: reach, impact, confidence and effort.
Before using this method we have to gather a lot of input in order to make it less gut feeling approach.
They have split their roadmap into 4 time columns:
- In progress
- Near term
- Mid term
- Long term
Theme-based roadmaps start with a problem statement and move towards a solution, rather than start with features and struggle to keep up with a far more rigid roadmap.
Sources that I haven't had time to research yet: