There are many inflection points along the journey of any new business. This post won’t offer you a cheat sheet for success or regale you with a particularly inspirational anecdote. Instead, it focuses on an acute challenge that I’ve seen every product and its team struggle with: building a sustainable roadmap. The post will cover common obstacles faced by new tech leaders plus how to form a roadmap in a growing team still establishing product/market fit.
The problem
Products aren’t defined by a presentation someone gives; outlining a golden vision of the future with ideal use-cases and trillion dollar target markets. Products are defined by helping individuals ease a chronic problem. This is true regardless of whether the product helps address professional (B2B) or personal (B2C) pain. The issue with building a product for individuals is that that they’re all different with differing wants and needs. This is where roadmaps come in.
The birth of the reactive roadmap
Few things in this world are as exciting as getting your first contract signed or your first organic signup; it’s a fantastic feeling and one you can’t wait to replicate as your user base grows. It does, however pose a new problem: your user base is now unified behind a single use-case. And in some situations, this use-case may not align with the long-term vision.
Now, you might scale from 1 to 1 million in a number of weeks, but if you’re listening to your customers (and you most certainly should!), you will always have an influential user group making demands on the future direction of your product. Identifying which of these demands benefit the mission is inherently difficult when the product is in such a juvenile state. In many cases, the vision is still subject to change (regardless of what we might tell ourselves). Even if you have a clear idea, you may have limited leverage or hard evidence with which to push back on requests that go against what’s most important in the long term. Even if there is a solid defence, the user is still perfectly able to walk away from the table.
I’ve seen product teams face similar issues with both B2C and B2B products as well as internally with their neighbouring commercial or operational teams. Empathising with the users of a product is imperative to its success, however there is a line and following the old adage, ‘the customer is always right’ has seldom resulted in the world’s best products.
Constructing confidence
While being overconfident in any venture often leads to missing the mark, teams struggle to break out of the reactive cycle unless they carve their own agenda and feel confident in pushing it forward.
The way to establish this confidence is unique. Some teams are very data-driven in their prioritisation; it’s therefore a matter of tracking the metrics that determine success (or failure). Others encourage intuitive actions and seizing opportunities as and when they arise. These constructs aren’t mutually exclusive, but each team will have it’s own set of values and principles that supports its successes and should use that as a platform for decision-making.
Once you have this platform in place, it doesn’t matter whether the source of work is a client, an engineer, a product manager or the CEO; their requests can all be prioritised objectively.
Establishing a proactive roadmap
There are two common factors that contribute to a request being addressed; importance and urgency.
You and your team need to have a shared understanding of what is important so that your backlog isn’t dictated solely by what is urgent. There is always a balancing act to be done when you’re faced with tasks that occasionally don’t match up with core values. However, effective teams recognise the necessity of these tasks when they do present themselves, as well as the impact they have on the rest of the backlog.
From experience, I advocate a ‘divide and conquer’ approach: divvy up your overall velocity in relation to what you determine to be important as a business. This minimises the risk that what is urgent derails what is important. Splitting the work of a product development team into the following buckets, you’re able to adjust the amount of focus on each according to their relative importance to the team at a given time:
- Product Roadmap — Development of new features and general progression of the product;
- Internal Roadmap — Addressing product and technical debt, tooling to help aid future development;
- Business as usual (BAU) — Bugs, client requests and anything else required to keep the lights on.
For example, if you’ve identified that a particular feature set or epic will unlock significant business opportunities, you might allocate 70% of the team’s time to Product, 10% to Internal and 20% to BAU. If however, the product is reaching its ability to scale, you might adjust that ratio to 30% Product, 50% Internal and 20% BAU. And, if the risk of significant churn has been identified, it might pay to go on a charm offensive, targeting those users and allocate 30% Product, 10% Internal and 60% BAU.
What does it all mean?
Every team will have its own natural balance across which buckets it considers most important and how much time needs to be allocated to each in order to strike a healthy balance. I’m a big proponent of running experiments to find this balance, by:
- Regularly getting the key people responsible for the team’s deliverables in a room (in the example above; the roadmap owners and anyone feeding into BAU);
- Reaching a consensus on the starting point for the allocations;
- Doing a weekly stock check to see what was worked on and whether that matched the team’s priorities; and
- Adjusting where necessary to validate assumptions and communicate the results
Once you have a transparent baseline, the team will have a better understanding of importance versus urgency regardless of whether you need to adjust these priorities regularly.
Establishing a format for discussing the company’s high level priorities is crucial not only when communicating within your team, but also to the rest of the business as a whole — proactive roadmaps allow you to keep these priorities front-of-mind for everyone involved.
Fergus Doyle is a consultant CTO and writing as a contributor for CTO Craft.
If you, or your CTO / technology lead would benefit from any of the services offered by the CTO Craft community, visit: www.ctocraft.com or contact us via email at: info@ctocraft.com