Would you spend $2 million building something if you had no idea what it would return? Obviously not.

Yet I've watched product managers do that, over and over. They commit resources to a feature or product, then handball the pricing (or value) question to the RevOps or marketing team months later. Why would you start spending money without at least a concept of the payback before you start?

I spent the better part of two decades building Aconex, much of it focused on the product. The way I approach product management changed enormously over that journey, not least because the whole product management landscape changed beneath us, moving from waterfall to agile around 2008. It also changed because I made plenty of mistakes along the way and learned from them.

This article is about the product-focused frameworks I share with founders now, based on that learning.

I've always felt it shouldn’t be called just ‘product management’; it should be called ‘commercial product management’. Before you build anything, you should be able to answer a handful of questions. What will it cost to build? What will it cost to maintain? Who is the buyer? What's the price point? How quickly will customers adopt it, and what's the churn rate?

Essentially, what's the ROI of this project?

Written down, it sounds almost insultingly basic, but in my experience, lots of product people are in the weeds of making more and better product, not thinking about the commercials of why they’re building.

In practice, plenty of teams skip it and burn resources on products that don’t move the needle.

Not everything a product team does has an explicit ROI. Some features are table stakes, foundational things you'll need to build for the solution to work, like scalability and reliability, or to have a seat at the table, like expected capabilities for your solution.

But even those face a commercial test: if not building something wouldn't dent sales or lift churn, it isn't worth building. The same goes for work done to manage risk. Uptime feels like an engineering concern right up until you're offline and customers start churning. Then it turns out it was commercial all along.

I found the people on my product team were sometimes intimidated by the financial side of things, so at one point I wrote them a "financial modelling for dummies" presentation. It helped our product team understand how their work contributed to the business's success. The stripped-back version of this is two questions: what will it cost, and what will we get for it?

I had one unfair advantage at Aconex: I'd lived the problem we were solving. But being a former customer only gets you so far, so for the first handful of years I made a habit of sitting on the help desk and taking calls.

I went on sales calls constantly to talk about where the product was headed and to watch how people reacted. The best product people are deeply embedded in their customers’ needs and problems in their day-to-day work. You can’t just ask customers what they want; you need to understand how they do their jobs, how their businesses work, and how their industries operate.

Henry Ford said that if he'd asked customers what they wanted, they'd have said a faster horse.

Maybe a better example comes from The Simpsons. Homer discovers a long-lost brother, Herb, who runs a car company. Herb is thrilled to meet Homer. Here, at last, is a true average man. Herb’s theory is that whatever Homer wants, millions of other average men will want too. So he gives Homer, the customer, free rein to design a car for people just like himself.

Herb offers no filter, no pushback; every thought from Homer goes straight to production. The car gets bubble domes, giant cup holders, and three horns that play “La Cucaracha”. The thing comes out costing $82,000, and it bankrupts the company on the day of the unveiling.

Pure customer input, applied without a filter, produces chaos. So, yes, listen to your customers, but pass everything through a filter that includes your organisation’s deep domain knowledge, a view of what good software looks like, and a sense of the next horizon your product needs to reach.

Sometimes your filter should say no. Let me give you an example.

In the early days of Aconex, general contractors were asking us to let them see inside their subcontractors' information registers. Their argument was that if they were paying for the platform, they should be able to see everything. We refused on principle. We allowed our customers to see everything they’d sent and received from a subcontractor, but never what those subcontractors had sent to someone else.

That was a philosophical position: neutrality. It built trust, and I think that trust was one of the key reasons we succeeded in the long term — even though it ran directly against what some of our customers were asking for.

At Harvard Business School, I was lectured by Clayton Christensen, the guy who wrote one of the most influential books on innovation, The Innovator's Dilemma. He was also one of the people behind the "jobs-to-be-done” framework, which has become such a part of tech shorthand that it’s easy to forget someone had to coin it.

He was inspiring for me as a younger founder, and he gave me the confidence to put frameworks around things I was feeling in the product team. One of those was a framework for allocating the product team's resources.

Product management’s main activities can be split into three buckets. And these activities will ebb and flow as your business matures.

The first bucket is to build new things. This is 100% of what you’re doing when you get started, and as you grow, it's about new products and features, the next big swing.

The second is to improve on what you’ve got. Products can feel stale without upgrades. You don’t notice the small incremental changes in products you use all the time. Although it’s similar to how it started, the Google Search bar has been constantly upgraded since it was launched in 1998.

The third bucket is about scaling and sharpening the saw: scale your platform so it can cope with growing load, and then sharpen your team through professional development and better ways of working for the organisation.

When you start, building new things is nearly all of it, as it should be. Somewhere around 12 to 18 months in, you have to cycle back and improve what you've already built. By 18 months to 2 years, depending on how fast customers are ramping, platform scale has to start getting real.

The biggest single step change in our product team at Aconex was structural.

Product management, UX design and engineering used to be three distinct teams that did their work and handed it across the wall. Each discipline wants different things. Product managers want to ship as much as possible, designers want design perfection, engineers want elegant code. Across three separate teams, those instincts produce head-butting.

Before we brought the disciplines together, engineering was the least satisfied group in our annual staff survey. A year later, they were the most satisfied in the company.

AI is now pushing this further, and mostly in a healthy way. The artificial walls between roles are blurring: product managers can prototype, designers can ship code, and nobody has to wait for something to happen behind a gate. Boundaries still matter. A world where everyone does everything is its own kind of chaos, where nobody knows who owns what.

But a little blur buys a lot of speed, and it builds the thing that actually matters: group ownership of the outcome that has ROI.