In my travels in Product Development over the last decade or so, I’ve seen up close the value destroyed and delays incurred as a result of falling into three common traps. They’re all seemingly harmless or perhaps even considered good, but there’s some serious downsides that only become obvious much later.
If you’re looking to grow your organisation’s impact, and get your products or platforms in the hands of more users, you should be on the look out for these:
1. Letting customers drive
To start with, this can actually be a good thing, at least when compared to the alternative where you’re simply following the hunch of a founder or senior exec. Listening very carefully to what actual paying customers are asking for is a great way to jumpstart your product and make sure it’s delivering value early.
This quickly becomes a problem though once you’ve gotten more than a handful of customers on board. It’s not an easy transition to make, going from being extremely responsive to customers, to being a little more careful with the things they’re asking for. You’ll know it’s become a major problem when you’ve got sales folks (who we love!) promising things to customers in order to make the sale. You’ve then entered the dangerous territory of “selling the roadmap”.
Selling the roadmap not only means you’ve outsourced decisions about what to build and what not to build, but because these usually come with hard deadlines you also end up cutting corners on a whole bunch of the how you build it as well. You very quickly find yourself nursing the history of rushed efforts you needed to do (worthy tradeoffs at the time), and that starts to really hurt your ability to move at pace.
Letting customers drive also tends to lead to strangely customer-specific feature sets, things that don’t necessarily set you up for broader success. The tradeoff is that your appeal to a wider set of customers gets weaker, and you end up more reliant on a small number of customers who have become used to using you as an order-taking waiter. You win a bigger slice of a much smaller pie, and that suits your customers, who now have outsize influence on your ongoing survival. By letting them drive, you put way too much negotiating power in their hands. Worse, they’ve got zero visibility of the tech debt you’ve created to keep delivering for them, with what are often unrealistic deadlines. They then wonder why the pace at which you can deliver their wants and needs starts to dwindle. Ouch.
I’d suggest you need strong in-house and dedicated Product Leadership to do this well. More on that a bit later…
2. Projects as the vehicle for change
You’d think after 20+ years of “uncovering better ways of developing
software by doing it and helping others do it” that it would now be accepted wisdom that Projects are the wrong vehicle for delivering complex change. Unfortunately, for a lot of organisations, this is still the primary mechanism for doing product development: It’s how budgeting works, it’s how prioritisation works and it’s how Capex is measured and managed. There’s a LOT more to switching from “Projects to Products” than just spreading a thin layer of Scrum or Spotify around. It’s a whole system problem. That’s not to say it’s hard to make the change, you just can’t do it properly without changing some of the surrounding pieces to better fit.
I feel like I’ve already said so much about this, but it’s still so prevalent that it’s worth calling out again. If your Product Development is using Projects as the primary mechanism for delivery you’re trying to bang a square peg into a round hole, and no amount of doing projects “better” is going to make it fit. It’s just the wrong vehicle. Projects works great in other realms, but the iron triangle of managing Cost, Scope and Schedule in Product Development is a fools errand.
You have to focus where you want to go, not on the negative things you’re trying to avoid. More focus on Value (early and often), Flow (smooth & short cycle time) and Feedback (fast and high Signal to Noise).
3. Separating Product from Technology
This one might be a bit more controversial, but I’ve seen enough of this panning out badly to think it needs to be more of a thing. So many orgs take up the mission to switch from Projects to Products, but don’t really reap the rewards because of the way they do it.
The crux of the problem here is the complexity of good decision-making in Product Development. There are so many different factors to consider, and there’s generally no single person who can really grok it all. Even so, when you have a person that’s charged with doing prioritisation for a team, but their reporting line and incentives are counter to a whole bunch of tradeoffs, then you’re always going to get sub-optimal decision-making.
The most obvious one here is the trade-off between technical options and the amount of corners being cut with each, and the timelines involved and when that value is likely to be realised. When Product is separated from Technology, the most likely result is that a lot of the technical trade-offs and complexity will get buried under what “the business” wants or needs.
Typically, the cost-of-delay for customers and the resulting commercial outcomes are more obvious to Product leaders. What they often don’t see quite so well is the technical tradeoffs. But you just can’t separate those two things. You might get away with it in the early days, but those tradeoffs have a habit of biting you in the ass fairly quickly these days. Whether that’s weak security, or poor scalability, or weak unit test coverage or slow paths to production, there’s so many ways this can surface in a really painful and expensive way down the line it really doesn’t pay to ignore it.
That’s not to say those tradeoffs magically go away when you bring together Product and Technology, but we should at least be more aware of them, and make those decisions together, understanding the tradeoffs and why we’ve taken the path we have. Together. And yes, that does require a somewhat enlightened group of Product Leaders, but if you don’t set up the organisation to at least see that, you’ve made it that much harder to align the teams doing the work and making those difficult tradeoffs a hundred times or more each week.
So, be careful how you design the org in this respect. Anything that smells like “order taker” either from customers OR within your organisation is likely to lead to problems.