Can Procurement Build Great Products?

I've been thinking a lot about one of Flywheel's biggest challenges. We don't believe waterfall software development is the best way to build great products. But can we sell something else?

If you aren't familiar with waterfall development, it's the way most software used to get built. It's a simple and intuitive process: write requirements, design the product, build it, test and implement, then maintain. It often gets lumped in with the SDLC, the Software Development Life Cycle, though that's really the broader framework and waterfall is just the old default model inside it.

In 2001 a group of developers wrote the "Manifesto for Agile Software Development." You should read it here: . It's short and to the point. That point is that waterfall doesn't work (or at least it’s suboptimal).

The idea that a founder's first intuition is always correct, that they have an idea and build exactly the right product for it, ignores reality. Almost every startup pivots, changes, and adjusts as it grows. This is well documented and usually well understood. Which brings me to our problem. Why can't our projects reflect it?

When clients contact Flywheel, almost everyone wants a fixed price project. It's extremely rare we can sell something that's time and materials or sprint based. For most agencies, and for clients for what it's worth, this isn't a problem. Everyone feels good about fixed scopes and prices. It keeps everyone aligned, and the agency can't be blamed for delivering exactly what the client asked for.

That's the problem I'd like to solve. How can we sell projects that match the best way to build products?

Our North Star, as a software studio, is to build successful products with great clients. It feels crazy that we'd contractually agree to a suboptimal approach, even when the client prefers it.

Which takes us back to the title. Can procurement build great products? The obvious answer is no. Procurement's job is to work with outside vendors, so it makes sense we work with procurement teams, but they aren't the ones calling the shots on the product.

Here's a definition I borrowed from the internet:

"Procurement is the end-to-end strategic process of identifying, sourcing, negotiating, and acquiring goods, services, or works from external suppliers. It covers the entire lifecycle, from forecasting a business or governmental need to finalizing supplier contracts, tracking orders, and managing vendor relationships."

Nothing in there is about building great, successful products. Depending on how you read it, you could even argue procurement's involvement is a negative. Their priorities have little overlap with the product's, except that both teams work at the same company.

But I don't actually think procurement is the villain here, and I don't think they're out to sabotage anything. They want to do their job, and their job is to derisk a purchase. That's the thing worth sitting with, because it's the same thing the product team wants, and leadership, and us. Everyone wants to derisk the relationship. Everyone loves a deal where they say "I pay X and I get Y" (fix fee) and feel confident in that trade. The more risk that enters the equation, the harder it is to work together.

So the fixed price contract isn't really a procurement problem. It's what everyone reaches for because it feels like derisking. You name a price, you name a scope, and it looks like you've taken the risk off the table.

Here's the catch. You haven't removed it. You've just moved it somewhere worse. A fixed scope locks you into the product you described on day one, which is exactly the day you know the least about what you're building. When that spec turns out to be wrong, and it usually does, every change becomes a negotiation instead of a decision. And quietly, the agency is now incentivized to protect its margin by delivering the letter of the spec rather than the best version of the product. Everybody signed something that felt safe and ended up further from a great product, on budget and on time.

So let's actually derisk it, for real this time. Let's identify which risks matter most for a given client and build the contract and the working arrangement to reduce and manage those, instead of pretending a fixed number makes them disappear.

And let's define success together and treat it as the North Star. I hate to say this, but not everyone's definition of success is that the product wins. In most businesses, success is just not failing. Weigh "the project went over time and budget" against "we shipped exactly what we promised and it flopped," and most people will pick the flop every time. Going over is a fireable offense. Delivering a dud on spec, on budget, and on time is not. That isn't cynicism, it's how the incentives are built, and it's a big part of why the misalignment exists in the first place.

Those aren't the clients we want, but we have to admit they exist, and sometimes it's hard to tell in advance. For us, success will always be whether the product met its goals. Timeline and budget matter, but they come second to that.

So, can procurement build great products? No. But that was never really the question. Procurement isn't trying to build your product, they're trying to derisk a purchase, and that's a job we can actually help them do well. The work isn't to get past procurement. It's to give everyone a way to derisk that doesn't quietly work against the product itself: honest estimates, development that's time boxed instead of open ended, and a real conversation about the pain points before we start rather than after they bite.

We're going to lean into this more. It'll look a little different client by client, because it isn't one size fits all. But done right, it's the version where everyone gets to derisk and we still get to build something great together. That's the win win, and it's the kind of project worth signing.