Delivering software: The Product Management Triangle

tldr; In this post, we discuss the levers you can pull to ship products. Inspired by the Project Management Triangle, we call the framework the Product Management Triangle.

For those unfamiliar with the Project Management Triangle, it looks like this:

It’s a model that identifies the constraints of project management. As Wikipedia puts it:

The quality of work is constrained by the project’s budget, deadlines and scope.

The project manager can use this framework to decide which levers to pull in order to deliver quality. It’s often said that you can only pick two of the three levers at a time.

How it could be applied to shipping software

Let’s realign the main goal for software. While quality is key for many projects, in software, shipping the product is paramount. Let me make my case: you can make the most beautiful and technically sound product but that won’t get your business anywhere without shipping a product. This is a highly relevant goal for tech startups that still haven’t reached Product-Market Fit (PMF). But it can also apply to any company whose product development is stifled by internal politicking.

For businesses with a software product, I propose a new triangle: the Product Management Triangle.

Shipping product

Shipping product is the centrepiece of the triangle; it’s the only way through which you can learn from users, improve your offering and deliver value. When shipping becomes your main goal as a software team, you’ll notice that the business will start to learn a lot faster from its customers and make more meaningful decisions. It’s what will move the needle for business. Seen from the flip-side, if you’re not shipping product, your business may be missing out on key insights and making decisions in the dark.

Speed

Cost has been replaced with Speed. While many projects have a budget (cost) component to improve quality, it doesn’t translate exactly in software. Adding more engineers doesn’t necessarily improve quality or expedite product being shipped; the Mythical Man-Month phenomenon would even say that your project will be delayed by adding more people to a project. Instead, what we can control is speed: you can write code with off-the-shelf libraries and frameworks, copy-paste templates and reduce the time spent debating technology. This has been talked about a lot in bootstrapping circles; instead of picking the perfect technology stack, focus on building and delivering value to customers.

Quality

Quality has replaced time. Time is covered somewhat by speed, so the next most relevant lever we can control as a product manager is quality. You can ship much faster if your code is half-baked or shoddy. This is far from ideal but it is still a lever you can pull. Need to ship something tomorrow morning? Hack together software and leave FIXME notes in the codebase. Fix them later. Yes, technical debt does pile up but that’s the trade-off: if you don’t ship, there won’t be anyone to tell you there’s something to fix.

Scope

Scope is still just as relevant for product management as it is for project management. If you reduce the scope of the new feature, you can get it out the door much sooner. It’s probably my favourite lever, as a more narrow focus is also good for business. The more complicated a product, the more the user will need to dedicate towards understanding and educating themselves about it. Conversely, with a very limited scope and very simple value proposition, the user will “get” what you’re trying to do and will see less of a hurdle to incorporate your product into their busy lives.

Pick two of three

As with the Project Management Triangle, you’ll likely only be able to use two of the three levers at a time. Let’s think about it: if you increase speed and reduce scope, you can definitely get the product out of the door quickly but it will be hard to improve quality at the same time; improving quality requires time, something that works directly against increasing speed. Similarly, you can increase speed and quality while getting a product released but you won’t be able to increase scope, as that would just increase the amount of things you’ll need to refine to maintain quality.

How to use the triangle effectively

The Speed-Quality-Scope triangle offers you the levers to control how soon you can get your product in users’ hands. But how you use those levers depends very much on what stage of development your product is in and where the business is at.

Early-stage business

I would argue a pre-PMF, early-stage startup needs to be shipping as soon as possible. There have been companies that built their products successfully in stealth mode (e.g. Improbable) but they are likely one of very few. How do you ship as soon as possible as an early-stage startup? My opinion: you want to pull the speed and scope levers to release your first MVP(s). Try to limit the scope of your product at the start so that it’s really, really clear to your users what they’re getting. If there’s too much included in your initial product, you’ll likely scare away users who don’t understand what you’re offering. Keeping the scope and messaging simple helps your users adopt and incorporate your offering into their lives. You can still ensure your product has reasonable quality while iterating with speed and reducing scope. By reducing scope, you may in fact be improving the quality of the product as you’ll have less to build and can focus on fewer things.

Post-PMF business

If you’ve already achieved PMF, you’re hiring and growing your product team, it will be hard to keep iterating at break-neck speed. Why? Because by adding engineers to your team, you’ll introduce organisational complexity, the need to ensure people aren’t stepping on each others’ toes and you’ll have an existing customer base to keep happy. If you stick to “break things, move fast” as a later-stage business, your early and late majority users (see Diffusion of Innovations) may become upset that your product keeps breaking. You’ll want to introduce processes to ensure that your product offers a certain level of quality: Quality Assurance, unit testing, integration testing and capturing user feedback post-launch. Therefore, your priorities will shift and you’ll likely be using the scope and quality levers more while shipping product. A reduced scope, as before, will ensure your product communicates the value proposition exactly and increased focus on quality will ensure your product will deliver the expectations of the early majority, late majority and laggers in your potential customer base.