Product Roadmaps for CTOs
How roadmaps and backlogs are an antipattern
How does a developer know what to code? Most companies guide development with a roadmap. This ignores agile principles and leads to waterfall processes. Roadmaps only work with deadlines which make developers feel miserable without need and leads to unsuccessful products. Therefore, you have to say: No, no, no!
As a developer, how do you know what to code each day? In today’s world we have a product manager finding products and features by various means and then steering development. A product manager breaks down the product into stories and features and with a process like Scrum or Kanban feeds those to the developers who then write the code.
How does a product manager know wh at products are the right ones? How does she manage what to build? How are product managers guided? In many companies this is done with a roadmap.
A roadmap is a plan about the future. It cuts the future into pieces and assigns work to them. Most often it is a string of features and products that need to be developed. Often the roadmap is a yearly plan.
Why do companies have roadmaps? Roadmaps give security. They show they have a plan. Roadmaps show they are not aimless. It is frowned upon when, as a manager, you do not have a plan.
Roadmaps are often used to coordinate departments. Marketing knows when product delivers something. Individual goals outside development are tied to roadmaps and the features on the roadmap.
Roadmaps are also driven by the desire for control. If you do not have a roadmap, what will developers build? Managers do not trust their departments; CEOs do not trust their companies to build the right things. With a roadmap, managers can feel in control.
When roadmaps can achieve so many things, why are they wrong? And also more interesting to me, why are roadmaps bad for developers? The main problem with roadmaps is you can’t look into the future. If we could, everyone would play the lottery. But we can’t. So, they plan for a future that will never exist. As I’ve written elsewhere about backlogs, as a startup we learn all the time about the market, about our customers, about what works and what doesn’t. This needs to change the things we are working on. A roadmap then often builds things that make no sense but are kept because of the law of inertia.
For developers specifically the worst aspect of roadmaps are the deadlines tied to them. As no one can estimate development time because of missing requirements, and companies don’t want to invest months for requirements engineering and estimations (and they shouldn’t!), products never fit into the time slots they are assigned on a roadmap full of products and features. This leads to half finished products that don’t work. It leads to features developers are not proud of and had to cut corners because of deadline pressure. The next feature is already waiting and has been promised to people in the company.
Often if some important deadline is going to be broken, developers in a company are shifted around. Developers are moved to the currently most important project. This leads to holes elsewhere in the organization and to a culture of patching holes. The developers need to familiarize themselves with the new code and productivity goes downm, while at the same time pressure to deliver goes up.
If a roadmap is used to coordinate departments it is practically impossible to change them, even if you learn that the stuff on them doesn’t work. Departments have built their own plans based on the roadmap and the product manager promised delivery of features and products.
Roadmaps are not agile. Agile is iterating and learning. Iteration means working on a product or feature until it works and however many iterations it takes. Iterate on an idea. When it works, or you’ve decided to throw it away, move to the next idea. Todays software development is the other way around: People use sprints as a resource to be allocated. Sprints, e.g. two, are allocated to a feature or even several features and then people hope for the best when it is finished. Then the team moves on to something else. In Agile if we have learned a feature or product does not work, agile says: Do something else. This is not possible with roadmaps, learning is forbidden. People, goals and careers are tied to roadmaps, hard battles have been fought by departments to get spots on the roadmap allocated, so resistance is very high to change them.
Does it make sense to have a plan? Yes, it depends what you put in it. Does it make sense to make detailed roadmaps? Perhaps it does in your environment, but then you’re not doing agile. With roadmaps one is tempted to do waterfall process dressed up in agile. With all the problems of waterfall processes in the first place. We can’t look into the future and don’t know what we will learn, so detailed planning into the future leads to build things that are not needed. There is this myth and attitude that if we do enough customer research and detailed enough planning, we will build features everyone loves. This way waterfall failed.
Roadmaps are pacifiers, they keep people calm and shut up, “my feature is on the roadmap”. They are there so someone didn’t have to say no. They pawn the future to happiness in the present.
Instead of all of this, say No!
Steve Jobs told employees in 1997 when he killed a feature Apples developer loved:
“But Apple suffered for several years from lousy engineering management. And there were people that were going off in 18 different directions - doing arguably interesting things in each one of them. Good engineers. Lousy management. And what happened was, you look at the farm that’s been created, with all these different animals going in different directions, and it doesn’t add up. The total is less than the sum of the parts. And so, we had to decide: What are the fundamental directions we’re going in? And what makes sense and what doesn’t? And there were a bunch of things that didn’t. And microcosmically they might have made sense; macrocosmically they made no sense. You know the hardest thing is …When you think about focusing, you think, well, focusing is about saying yes. No! [And] you’ve got to say No, No, No … and you say no [and] you piss off people […] You want to be nice […] The result of that focus is gonna be some really great products where the sum is much greater than the sum of the parts […] Focusing is about saying no.”
What works beside saying no more often? Implement features with which you can maximize learning, then implement what you have learned. Often very small steps are needed to learn something. Base roadmaps on goals/objectives and not on products and features. The objective for next year is something that will change your company. Put something there as an overall objective. After you have achieved it, the company is no longer the same but on the next level. Breaking down to a roadmap put goals on the roadmap like “Quarter 2” is “Increase conversion for Traffic from Developers by 10x”, “Quarter 3” roadmap is “Reducing churn to Zero for Premium Customers” and not products or features. This will align and focus the company without getting into detailed future commitments.
Start each quarter with an empty table - tabula rasa - and not with a backlog or a roadmap filled with features and products. Build what needs to be built in that moment. Do what need to be done for the success of your company in the marketplace.
For developing features and products push down responsibility as far as possible. Self-organized product teams decide what to build. Self-organized product teams decide what not to build. Self-organized, cross functional teams are responsible for the success of their work. They are guided by objectives which help them to make decisions.
These teams iterate until they have product market fit (or feature market fit). The market and their customers use and love the feature and product. Do not start something new until you’ve scrapped the feature, or it flies with your customers. Measure feature usage: Are they used or are they not used? Decide what percentage of daily users who use the new feature or product are a success. Think about what you need to change in the next iteration to make it work.
In many companies product teams get diverted from requests by marketing or other department (sometime by the CEO). Build a new landing page, build a new lottery, add some new tracking, integrate social media or integrate HubSpot. Have a dedicated team for marketing and other departments, which only builds marketing integrations and landing pages. Your product teams focus on building the product. This will remove the pressure to put things on a roadmap, as often marketing wants a roadmap and their features on the roadmap so they are – rightfully - not forgotten and can plan their campaigns. Decouple marketing campaign planning from building successful products.
In the end, stay agile, learn and change direction accordingly. Build things that work, don’t allocate time for building features, iterate until these works Developers will be happier when they build things that people love and not another feature with low adoption.
Happy Coding!
