TBM 230: From Prioritization to Accountability (and Autonomy)

Some quick advice to product leaders—especially leaders involved in discussions about efficiency, productivity, and ROI:

If you don't provide your product's investment and governance framework, one will be provided to you. And the person providing that framework (e.g., finance, sales, or marketing) will not create a framework that is friendly to making great products.

You must dictate the game, or the game will be dictated to you.

I am not referring to prioritization. Prioritization is important, but given that some uncomfortable % of things we build fail to produce the intended outcomes, it is only a small piece of the puzzle. Most prioritization frameworks are used as "feel good" frameworks. Teams engage in a ceremonial act of performative diligence and pseudo rigor—weights, scales, and scores—to avoid the really hard conversations. Does anyone close the loop? Or are they too busy with the next planning cycle?

Instead, I am talking about 1) a progressive funding model and 2) a model for holding yourself accountable for what you do with the company's money. I'm not normally this harsh and transactional, but realistically someone will think like that—so it might as well be you.

In many companies, the funding model is: "Give us money to build the stuff you want us to build, and do the barest minimum of maintenance on the stuff you asked us to build in the past." To fulfill your end of the bargain—to be held "to account"—you deliver the stuff when you promised to. When it comes time for annual plans, you make a big list, draw a line, and say, "If you give us more, you'll get more!"

Of course, the result here is a mess of poorly maintained features and products, a mountain of debt, a big team—hey, you needed all those people to build all that shiny new stuff—and a lot of people asking you about ROI, and how to keep costs down.

In this model, you're playing the internal software development contractor game.

Consider a different game more similar to a startup/investor game.

You pitch your product to the executive team, and they invest in a "seed round." The money doesn't pay for a list of projects or to cover staff costs indefinitely. You establish some strategic and tangible funding milestones. When/if you get there and the business re-ups, the re-upping is not just to sustain the current trajectory. It's an opportunity to pivot, scale, or even sunset parts of your product based on the last milestone's feedback, results, and learnings.

The goal isn't to have the biggest team. Rather, it is to build a business (that is part of a business).

This game encourages a mindset shift. It moves teams from merely delivering features or projects to becoming stewards of investment and growth. The game makes sustainable, differentiated growth the goal. When you generate profits or achieve sustainability, you can fund your growth, just like a successful startup in its later stages. You control the growth of your product, make strategic decisions, and guide its trajectory in line with your vision.

Yes, this is higher stakes. And yes, playing the internal software development contractor game might be easier. But ultimately, you control more of your and your team's destiny. You control the narrative.

10 questions to guide this activity:

1. Would you fund your team if you controlled the budget?

2. What might you observe to increase confidence in the investment in your team/group? What milestones might you hit? Imagine walking into a quarterly meeting and sharing qualitative and quantitative data to understand progress. What story would that data tell? What are the stepping stones?

3. Imagine some financial statements. You don't need to be precise, but imagine you built nothing. What happens to those metrics?

4. Have you proven yourself as a small team? Or are you floundering and asking for more headcount to gloss over a core issue?

5. How are the unit economics trending?

6. Where are you in the hill-climbing process?

7. Where are you in terms of your value curves?

8. What game is your product playing?

9. How is your product work contributing to sustainable, differentiated growth? What are the inputs to that growth?

10. Assuming you work in SaaS where the product is never "done," how does your work on improving existing functionality impact the company's near-term and mid/long-term financial outcomes?

I’ve been writing about games for a bit: Part 1, Part 2, Part 3 . In a sense this was Part 4.