Funding your Product Roadmap
How do you ask for funding as you scale your product & team?
You have a product roadmap (annual / multi-year) in front of you, crafted by you after months of deliberation, discussions, conversations, stakeholder and leadership feedback and reviews. You take a step back to make sure it’s aligned with your company OKRs and product vision. You also have the buy-in from the right stakeholders who will evangelize your cause when the time comes.
However, this article is not about how to create that perfect roadmap. I’m going to talk a bit about how to get those funding dollars in order to make your roadmap a reality. Especially in the context of scaling your team i.e. when you already have a mature/ish product and are aiming to broaden your product into an enterprise wide platform over the next few years. What considerations do you need to keep in mind while you open up the conversation with your partners regarding funding $$?
Get all the information before you open the discussion
Both in terms of estimated “value” of those initiatives and the estimated effort required to make those initiatives a success.
Make sure to have high level estimates (T-shirt size — H/M/L ) ready from both an app-dev (engineering) perspective, but also from a product/business/risk/support/sales perspective. In majority of the cases, you narrow down the $$ to a T from an engineering effort side, but forget to include product discovery, ideation, support-enablement work from other functions (basically product, design, marketing and more teams will be tied up with their mental and physical energies whilst working on these projects, and hence their work effort also needs to be taken into account during roadmap planning).
Going a step forward, convert those t-shirt sizes into $ estimates based on work effort, salaries, technology infrastructure upgrade, marketing costs and more. The idea here is to estimate the number of resources (in engineering-dev-product-marketing-sales-etc) you think might be required for an initiative and the time (months) it’d take for them to launch this initiative successfully.
Also keep information ready around the implications of not building certain initiatives/projects.
Understand the implications across the team
Your platform is bound to get more complex as it grows and scales and hence as you add more capabilities into your burgeoning platform, there’s also an opportunity to invest in supporting those capabilities, building resiliency and stability within the platform, having robust processes around change management, bolstering training &sales/marketing and customer support enablement and so on.
If you’re asking for (more) money, you’re building things faster and hence a few questions to ask yourself would be —
- Do we have the processes in place to support a growing platform? If not, what needs to be accomplished before we take on more work?
- As we keep adding more stuff, where will be the break point? Making sure we slow down or minimize the reasons for that breaking point.
- As the team scales, is it ready to sustain itself? Are we ready to take on additional stuff, to sustain the cash cow product and the experimental big rocks?
- Are we ready to support the additional influx of users/customers as we scale the platform?
- Since there will be more people across the board in your team, what do we need to bring them up to speed quickly? Do we have the time and processes to transfer knowledge and bring new members to a level playing field? If not, what can we do now to remediate it?
Hence as engineering and product evolves, there has to be more emphasis given to growing other team functions (design, marketing, sales, support etc.) as well as to scale the product/team in a holistic way.
A way you can structure your ask -
I’m asking for so much money for the product— and this is how my team should look like as well.
Types of initiatives — MVP vs. full blown capabilities
There will be initiatives which would require the rigor of full-blown competitive products, whereas others might be driven by an experimental approach — a scaled back MVP to understand the product-market fit.
How much time do we invest in each of these? Do we have a phased approach for certain initiatives?
Some capabilities might require more testing effort than others , some might be more complex than others. Hence how would you approach the conversation around it?
Your approach to asking for funding
There are two ways you can ask for funding —
- Work backwards from a given available funding number
- Ask for funds for each line item in the roadmap
In the first approach, you’re forced to prioritize the items given that you’ve a static funding number from the executive leadership and you need to work backwards from that. Hence more thought is put towards what is absolutely essential (vital), must have over the long run (high priority items), low cost tweaking (possible optional items) and not required — basically the MOSCOW prioritization method.
The same kind of (and level of) prioritization might happen when you put forward a roadmap in front of your executive committee and ask for a $ number/range for the entire roadmap. However, in this approach, there will be more conversations, push backs and requests for ruthless prioritization.
There are nuances in each of these approaches, and one approach is not better or worse than the other. It might totally depend on how your organization is structured and the process it follows to provide funding, or it might also depend on where your product/platform is at. If you’re an early stage product where you still need to prove yourself in the market, you might get a certain number that you need to work off of to prove your product further. If you’re a mature and growing platform, you might have the freedom to be nonchalant and outright whilst asking for funding without a hard limit (given you back it by your product & team performance, prioritization and reasoning).
Dependencies with other teams/ business groups
Some parts of the roadmap might be completely encased in your ecosystem, whereas there will be other items which might be built by other business groups or in collaboration with other teams. Re-usability and reducing redundancies will be key here. Hence understanding what dependencies exist on your roadmap, getting buy-in from those teams and bringing those partners in on the funding conversation will help speed up the process mightily.
It also helps to get this conversation started much before you put that item in your roadmap, given those business groups/teams would have roadmaps, timelines and priorities of their own — you will have to fit in yourself in their roadmap as well.
A key part of this discussion is also crafting the idea around how this roadmap will deepen partnerships and create 10x impact on other LOBs across the enterprise.
Other considerations
- Vision is key. Before presenting a roadmap to stakeholders, elaborate briefly on the current status of your product and your vision for the product going forward — basically the ‘outcome’ of the entire roadmap. The roadmap will be the stepping stone that will help you fill the gap between your current state and the vision you’ve dreamed about.
- Strengthen your case with data, research, customer stories and buy-in from other vocal and strong stakeholders.
- Be explicit with your ask and the support you need from your executives, peers, teams & other stakeholders.
- Think about how will you scale the product in the future, how will it positively impact other parts of the organization i.e. how will it help the company scale it’s operations in the future.
- Ask — Is this the outcome you’re thinking about as well? Is there alignment between us and you
- If the roadmap consists of a few options, put the options in front of everyone and provide your concrete recommendation; never leave without a recommendation from your end. Your input will help the exes through their thinking.
- Make sure you tell a compelling story with your roadmap, rather than talk about stand-alone products & capabilities that don’t talk to each other. You need to think of the roadmap as one story/journey towards the end vision, and communicate it to the executive committee.
