Why do we so often ask teams to estimate in detail how much effort is required to build a product, and to that upfront? There’s evidence that this lead us to output-oriented thinking, premature optimization, bloat and generally a commitment to suboptimal solutions that are designed with too many assumptions and a lack of clarity on the problem space. Yet the main reason, I’d argue, is that estimation is an entirely rational risk mitigation strategy. Some of the reasons might be that: 1) we’re promising to build a product for price X, when it’s going to cost us more than X-M, where M is our minimum acceptable profit margin. Maybe we don’t want to build this thing. 2) there are explicit and irreversible costs to not meeting a deadline and we want to minimize the risk of not doing so, so that we can organize and dedicate appropriate resources to it. 3) we are uncertain of the returns it will yield, so we want to be sure that we’re not over-investing vs what we have in the bank. That’s all fine, but I argue that diminishing returns to estimation happen pretty early in the effort scale, and discount your ability to respond to future ambiguity. Teams should focus on simple, transparent budgeting, asking themselves a few key questions: how much runway do we have to build this? E.g. a start-up may need to get a particular feature out the door in about a month to test market appetite. A scale-up might need to deliver a big product stream within a year to capture the returns of that investment in the next financial exercise. how much of that runway do we want or need to bet on this particular problem? Is it a bet the company move? Are we hedging our bets with 3/4 major plays? Are we just seeking initial validation? Do we believe we need to acquire additional resources in order to fund these goals? Why? Is there anything we could drop instead? Do we know enough to make the decision? Clarifying Runway Teams should be formed and funded to solve a specific problem or need, not given a fully shaped answer already. Understanding and negotiating the right runway to answer a given question upfront is an important part of the process. Follow-up: How much funding do we need to figure it out? Can we meet in a few weeks to talk about what we’ve learned? Do we know the problem we’re solving well enough? F: How do we break this down? What’s our first goal and how much budget do we want to allocate to it? Does this look too big for our team? F: Are we likely to run out of runway to tackle it or can we solve with the current constraints? Have we discovered a major hurdle or roadblock? The right level of constraint fosters creativity, productivity, and agility, so managing your burn rate towards your expected outcomes should be a fundamental part of your day to day discussions. When questions such as the ones above arise, when you can’t solve them within the budget you have, there’s a frank conversation to be had with your investors (either internal or external), to get a portfolio take on it and use your voice in a forum where you can advocate for the right resource structure given your current level of knowledge. as a team Betting Now when you’ve worked out your current runway (give us 3 months to work on this), it’s up to you as a team to decide how best to use it. People should share a stake in outcomes, so that they’re accountable and responsible for their achievements. For simplicity’s sake let’s take money out of the picture. You have 5 highly qualified team members and 12 weeks of runway. Each team member gets 12 coins, which they can spend as they please. They can use it for experimentation. They can use it to solve technical debt. They can use it for foundational work with a longer payback period. They can manage their ROI horizon so long as there is team buy-in. As a team, your communication becomes about whether you’re using your runway the right way given the problem you have to solve, how much do we believe in our solution, how much evidence we have to back it up, and how to we maximize our personal time investment. A great product manager, I’d say, maximizes this ROI function for their team. They devise the right investment strategy proposal, offer their teams the right level of information so they make informed decisions and good trade-offs, and continuously evaluate and communicate said strategy in the presence of new information — did we get results back from users? Are we becoming more confident about the value this represents? They also let others take the lead and own solutions, emergent problem exploration or resource allocation plays, devoting their time to synthesising the outcomes into a good map of where we’ve been, what we know, and where we’re headed. Are we getting bang for our buck? Funding Finally, acknowledging that you need funding as early as possible in the process, whether it’s in the shape of time, money or both, is important. “Gotcha!”, you’d rightly say right about now. In order to know whether you need funding, you’d have needed to estimate whether your runway is sufficient to meet your goals. I don’t disagree. I argue though, that accuracy gains in product development estimates are quickly offset by the time and cost of those gains, particularly for complex problems where you have too many unknowns and need to make up assumptions to move forward. You should be making a continued assessment based on risk and reversibility while reducing unknowns and assumptions using a diverse set of viewpoints and tactics. Set your ego aside and ask honest questions, be open to change, be confident enough to bet. Reviewing and Restructuring Once you start budgeting and funding, as you become better at breaking problems down, identifying key assumptions, incorporating new information, assessing risks, potential returns, modeling your predictions and even improving your productivity, deep and detailed estimation will become much less important, while systematic flow will grow in relevance. We’re able to define bite-sized chunks of our larger meal, and use what we’ve learned to move forward in the right direction, gaining momentum. Keeping a healthy bets portfolio and shipping consistently against it becomes ever more important and reviewing your investment strategy often, understanding the shape of each of your investment’s returns, is a fundamental exercise. At a portfolio level, organizing teams in relation to the structure of your needs, your runway, and your risk level becomes the better lens through which to look at the world and gives individuals the authority to go out and discover the best solutions to your current problems, especially with healthy and regular feedback mechanisms in place. Previously posted at . Building Fast and Slow: Budgeting as a Product Team

Flow

Funding

Check out my product playbook

Read My Stories

Too Long; Didn't Read

Developers: Build Less. Deliver More. [Learn how]	

Product Teams: Stop Estimating, Start Budgeting

Too Long; Didn't Read

Company Mentioned

Coin Mentioned

Carlos Oliveira

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Product Teams: Stop Estimating, Start Budgeting

Too Long; Didn't Read

Company Mentioned

Coin Mentioned

Carlos Oliveira

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES