The Iron Triangle is a nice way to visualize the eternal struggle of product and project management:
Scope, time, and cost are the three levers you can pull, and each of those has an impact on quality and customer satisfaction. Highly simplified but you get the point.
This begs the question: if you have budget or schedule pressure and need to cut corners, which corners should you pick to generate the best outcome? Project managers typically have tremendous difficulty answering this question -- they are great at pointing out that things will slip, or quantifying a cost overrun or schedule extension, but if budget or date are fixed they will often punt back to the business, and not unreasonably so. Product managers typically don’t have that luxury. The list below is for them.
When the chips are down and you need to save time, money or both, here’s the stuff (in order) which I like to cut:
Pixel perfection
Especially in non-Agile environments, up-front design tends to be one of the largest line items; you spend a lot of time making something pretty, in part to convince yourself that you should spend even more time and money building it. The early stages of product development should be words on a page and rough mockups, backed by a healthy amount of research and reasoned argument. The user experience is crucial but can be iterated; doing visual design up front is often wasteful. And visuals and flows can always be improved, even post launch.
This is not to say that design is a lesser partner to product and tech in the development process -- it absolutely is not! But pixel perfection is also something which matters more to stakeholders than to customers, and as such can often be trimmed without negative product impact. Make something that feels a little rough but works perfectly, and you may find that looks don’t matter as much as you thought. Note: this is more of an upfront adjustment -- doing less monolithic design at the beginning of a project can create room for you to absorb scope creep, and you can add that design effort back in later if schedules allow.
Features
Even the most perfect products have features they don’t need. Sometimes they are vestiges of an earlier iteration, other times they are HiPPOs (highest paid person’s opinions), and they can also be reasonable bets which didn’t pan out. The most impactful thing you can do for your product is to narrow your focus to the one thing you think will move the needle. This could be a single user persona, or a single Job To Be Done, a single new feature, whatever works. But the best way to rein in schedule is to admit that not everything you’re planning to build needs to be built, and you don’t know which is which. Don’t be afraid to make bets -- groom your backlog to ensure you are always working on the single most important thing you can. You are done when the product works, not when you got through the list of all the stuff you said you would build. (See Rhythm, Focus, Vision and story of COO + focus)
Architecture
Technical debt is usually considered to be the inevitable consequence of building and iterating -- it accumulates, you have to pay it down constantly so it doesn’t build up, etc. There are also times where you may choose to “take out a loan”, and intentionally create new tech debt to accelerate a product goal. The best example of this is where a new feature or chunk of functionality requires an architecture change. If that architecture change is going to cost you your deadline, you can choose (with support from tech leadership) to do something quick and dirty and then come back later to fix the damage. This carries significant risks, but can be worth it if you feel you are spending too much effort building the perfect mousetrap and not enough catching mice.
Automation
Sometimes schedules can explode because tasks which are manual must be automated “before we can scale”. However inelegant manual workflows may be, they are often the right choice at first. Manual tasks, especially while proving product/market fit, can be very efficient -- you can pay a non-technical person to do them and ensure they are done right, they can be changed through simple instructions rather than code/QA, and when the cost/benefit flips over you automate them and the pain goes away. This is especially true of MVPs -- MVPs should have manual labor involved! Automating something you don’t know is going to work is a poor use of resources.
Process overhead
Sometimes teams will complain about paperwork, or about too many meetings, either with others in tech or with the business. This is one of the key tensions in Agile -- the rituals exist in part to push back on deadline pressure and free teams to do their best work, but teams can chafe when they know a milestone is important and feel they know what to do to get there. Process is not always greater than progress. That said, processes exist for a reason, and process waivers should be explicitly temporary. Cutting off contact with customers or your stakeholders may sound like a great way to gain hours in the day, but when you resurface to a different set of requirements, you may wish you had taken the meeting.
Customers
Supporting too many different customer types is a common flaw, especially in mature businesses -- ideally you balance the cash cows with the emerging opportunities and everybody gets fed, but it can be very hard to admit that a customer just isn’t worth supporting or investing in. A good product opportunity assessment framework can help with this, either when kicking off a new effort or something already in flight. And we are not necessarily talking about cutting off customers, but figuring out whether to invest in one part of the product and sustain or sunset another. The hardest part of this is telling a salesperson that his customer’s pet feature isn’t getting built -- you as a product person are letting down a friend, even if they agree their customer isn’t the right place to spend resources. But the returns on those decisions can be substantial.
Quality
Now we are in last resort territory -- but every team has to consider what level of quality they demand before putting product into the world, and most teams frankly set a higher bar than they need. I have seen some product teams spend so much effort on QA and bugfix that they never ship. Don’t be that team. Known issues are just that -- issues which you know exist, and affect real users, and which at the present moment are not fixed. If that kills you, you may want to investigate a new line of work. If you have major issues that prevent people from using your product or will kill your customer service team, hold your horses and fix those problems, but the best teams know that bugs happen, and they know a show stopper when they see one. Get good at bug triage, and at saying no to fixing minor bugs when appropriate.
I hope this list is helpful, especially to junior product managers, who haven’t been around the block enough times to know what happens when they break the rules. Much of product management is feel -- knowing when to do things by the book because the org needs discipline, knowing when to let teams do their own thing because they’ve earned your trust, and seeing the first signs of things going off the rails before they are too far gone to recover. Building product is messy and hard, even for the pros, and the more tricks you have up your sleeve, the better.
Dan Mason
