How to build a roadmap while staying agile and lean, and why so many product teams do agile wrong.
Bottom to Top Agile
In many companies that make a transition to agile, the move is initiated by engineering, which is focused on execution and efficiency. The rest of the company (product management, project management, sales, executive team, marketing) might be left behind or only be partly included.
Too many times, the whole agile process becomes “religious” and focuses around the sprint and the sprint rituals instead of what it means to be agile. There is sprint planning, a daily, a retrospective, and a demo. CollabNet VersionOne state in their 12th annual report that 94% of organizations practice agile, but only 14% are doing it maturely.
It does not matter if the method used is Scrum, Kanban, or the hybrid Scrumban. You can be agile without sprints, and you can do sprints and still not be agile. As long as the team focuses on making only the execution process agile, the result may still be an only improved waterfall (or what is nicknamed Agilefall).
The Agile Manifesto
People forget that agile is just a means to an end. While working on the implementation of agile process, too many people do not understand or take the effort to learn the basic agile principles mentioned in the agile manifesto, which are:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Agilefall
If product management makes long-term commitments of solutions to the business, and writes long specifications, which are later broken to sprints by engineering, the whole essence of agile is missed, and it just becomes a more effective waterfall.
If you do too many detailed requirements, you fall in love with them, and you are not building a real MVP. Some of the characteristics of Agilefall include:
Committed roadmaps initiated mostly by marketing, sales and executives.
Long sprints or sprints defined by scope rather than timeline.
Hard commitments of specifications to business that span many sprints and many long-planned release dates several months in advance.
Long design and specification cycles.
Too detailed sizing efforts.
Sprints are internal without any release and feedback from customers.
And more …
I suggest further reading Product Fail and Revenge of the PMO by Marty Cagan for more fallacies of waterfall methods creeping into agile.
Agile Product Discovery
Agile culture should start with the executive team and product management, while agile process should be initiated by product management and engineering. It should follow the lean startup methodology, even if some small things need to be adapted to corporate culture.
It means that as a product manager, you should always iterate on what you do next, and re-consider your plan every sprint. It means you must involve your engineering team in the discovery process in order to innovate prototype and evaluate what may bring better value to the product and to your customers.
The team must first focus on what to do, and not just on how to do it. While they are both important, what to do has the most impact on product success.
Outcome vs Output
Execution is about output, and most agile teams measure themselves by velocity. While it’s very important to be efficient, it is a misleading metric. The statistics are very sad. A research by Standish Group claims over 64% of developed features are never or rarely used.
A product team should focus on outcome and not on output. They need to check whether the feature they delivered does what it was intended for. They should focus on the results. To properly do it, you need to ship it fast to customers, check its performance, and iterate on the solution, until the wanted outcome is reached (see also When Performance Is Measured By Results).
This process is usually referred to as Build-Measure-Learn feedback loop, a concept taken out of lean startup methodology.
Plan with Problems
The challenge with what I have depicted above, is that most of us do need to plan at least a quarter ahead and sometimes a year ahead. We need it to commit to our stakeholders and to our customers. We also need a roadmap to focus the team and create a NorthStar to guide us.
The answer to that is to commit to the business problems you are going to solve and not on the solutions that solve them. Your plan ahead should be a set of KPIs and initiatives that communicate directly with the business goals. Once you have such a plan, you can iterate every week on how to solve things properly without breaking your commitment. It enables you to be autonomous, empowered, and aligned with the business.
On a yearly basis, you usually want to commit only on metric improvements. On a quarterly basis, you may commit on some initiatives and features, because you may have done some initial discovery that gives you enough confidence that a specific initiative will produce the right outcome if done correctly, and you want to be less vague with the team. Good constraints and frameworks usually make people more productive than vague goals.
Examples may include:
Commit to how much cost you want to reduce rather than how you plan to do it.
Commit to increasing user acquisition by x%, instead of improving the signup process or its design.
Commit to moving to a new architecture or solving a technical debt, rather than how you do it.
Commit to launching a new user experience, instead of getting too fast into the details.
Commit to launching a new product, rather than on its specific features.
See also The Alternative to Roadmaps and The Problem With Product Roadmaps.
Squads and OKRs
In a small organization you can keep the process loose and follow the guidelines I have mentioned in Own your product management on-boarding. You can break it roughly into the following actions:
Define 3-5 yearly goals.
Out of those define 2-3 quarterly goals and prioritize them.
Define initiatives and problems you want to advance/solve in the next quarter.
Roughly T-Shirt estimate them and tie to the goals.
Prioritize the initiatives (it should be easy now that you mapped them to the goals).
Based on resources, try to understand what you do in the quarter. Be generous. Keep some space for unplanned things to squeeze in.
Revisit at least once a month.
In big organizations a better framework is needed. The framework is used to enable the whole organization to work loosely while synchronizing on the right goals. The frameworks I found useful are squads and OKRs.
Squads are autonomous product teams that have all the resources they need to execute their business goal. Their goal is usually derived from the business and they are free to pursue it however they seem fit. An example may be a squad in Facebook who is responsible to increase the number of friends you connect to (because it increases the value you get out of Facebook). A feature such a squad may produce may be “friends you may know”). More on squads in Spotify Engineering Culture.
OKRs stand for objectives and key results and are a way for the whole organization to define objectives transparently and measure itself. It is another way to make sure you focus on the goals and problems and not make a roadmap of solutions. In OKRs you tell the team what you need them to accomplish, and how the results will be measured, and let them figure out the best way to solve the problems. More on OKRs in How Google set Goals.
Minimal Backlog Policy
Many things have been written about Zero Bug Policy and why it is effective. If you keep a bug you don’t plan to fix now, it just consumes your time. The time spent on prioritizing bugs could have been spent better.
Backlog is no different. The worst thing you can have is backlog items staying in your backlog for too long. You spend a lot of time revisiting them again and again, and when you finally decide it is time to implement them, you find out that what you wrote 3 months ago is no longer relevant and you need to rewrite everything. Usually because you have already done it, you also have less passion to do it again, and the end result is not as good.
Having too many items in the backlog also creates the tendency to think about what we already have in the backlog instead of thinking freshly about all the things we may need to do, which might not be in the backlog.
Keeping the roadmap at the problem level ensures that you work on the solution only when it is really time to develop it. It may be 2 weeks before for a small feature or 3 months before if it is a major user experience overhaul. Take whatever you need to properly define the minimal change (and not the maximal), but not more than that (Always think MVP). Don’t start working on a feature going to be implemented 3 months ahead just because you may have the time now. Focus on strategy or customer interviews instead.
Just like zero bug policy, if you wrote a detailed specification for a feature and then not to implement it in the near future because priorities have shifted, it is sometimes better to delete it from the backlog instead of revisiting it again and again.
Summary
By focusing on the problem and not on the solution, you gain the following advantages:
It is easier to focus the team on the right things.
It is easier to let your team innovate.
It is easier to prioritize, because things are defined at a higher level.
You do not waste your time too early on the details.
It gives you more time to focus on strategy as I mentioned in Make yourself “Redundant”.
Be Lean and Agile.
Also available in hebrew as a podcast episode: "מפתחים חסרי תרבות - בני רייך מתכנן בעיות"