The missing piece of software product requirements: Price

In general, product teams output product requirements. These artifacts can come in all sorts of shapes and sizes: a user story, product requirement documentation, feature request.

Yet many (most?) of the templates that I’ve seen online about these artifacts miss a critical component: the price. My fried Bjorn, who’s a software psychologist, introduced me to the concept of including price and I’m now a believer.

As a product manager, set the price that you’re willing to pay. The clarity of a price aligns engineering with the business value of your requirements, helping everyone make better tradeoffs during the development process.

Specifying price

How do you specify price? Simple: engineering/weeks (or equivalent). For example, a small feature might be 2 engineers for 2 weeks. At Ambassador Labs, our engineering organization consisted of teams of 4 - 6 engineers. Then, we would stipulate price in terms of 1 team for X weeks. We tried to manage the general size of each project to be anywhere from 4 weeks - 6 weeks. In shorter cycles, you can’t build anything too complicated, while longer cycles have a higher probability of going sideways.

Why is price so important?

Price is important because not every software requirement has the same value to the business. Price is how the business value of a requirement is communicated to engineering.

For example, while dark mode is popular, I might not see a huge effect on customer acquistion, which is the business priority. So it makes sense to set a lower price for dark mode, versus a higher price for a better first-time user experience, which has a much higher impact on revenue.

Product scope negotiation is broken

The common approach to engineering / product collaboration is a negotiation. Product writes the requirements document. Engineering digests it and gives a rough estimate of the effort required. Then, a protracted negotiation around scope commences. The final output is an agreed upon scope and effort estimate.

This process has two immediate problems:

1. It’s very resource-intensive. Lots of high-level individuals spend time in meetings to make sure scope is very clear so both product and engineering can appear to be successful.
2. Inevitably, the final scope and effort estimate is off in some material way.

The bigger problem, though, is it disincentivizes the engineers from thinking about the users, and outsources all the thinking to product managers. Product organizations then need lots of product managers who inevitably are negotiating minor scope changes instead of focusing on the features that drive business value. Essentially, without pricing, most product organizations become incremental feature generators, instead of identifying opportunities to drive business value. )

Venture capitalists get this right

Engineers push back on the fixed price concept by claiming it’s infeasible. “We can’t guarantee we can ship something on the budget you set.” I would respond and explain that the real-world doesn’t operate this way, and point to venture capital. A venture capitalist never says, “the goal is $1M ARR; please take as much time and money as you need to get there.” Instead, she says: “Here is $2M in capital. Get at last X paying customers.” The VC writes a bunch of these $2M checks. Some of them will pan out, and some of them won’t. But she has managed her risk by putting a maximum price on each investment.

Product needs to work the same way. Here’s the price I’m willing to pay. Engineering’s job is to figure out how to ship the core of a product specification, on-time, within budget. And sometimes, they might fail. But in that case, the cost of the failure is capped at the price.

Organizational implications

I noticed two major implications for product and engineering when adding price.

First, creating realistic prices required product to engage with an architect, technical lead, or CTO to choose a realistic price. There was a natural back-and-forth to this process, and having a technical background in product was very helpful.

Second, our engineering leads (and ideally, every engineer) needed customer empathy and the willingness to manage to a business goal. This was a big surprise to me, as we definitely had engineers who were much more comfortable with well specified issues. The engineers who did well in this world were great at understanding the business goal and then making reasonable tradeoffs to achieve the business goal.

So: set a price, and build what matters.