7 Deadly Sins of Product Development: A Guide to Avoiding Disaster

OK, we admit it, there are definitely more than 7 deadly sins of the product development process. In fact, there are probably thousands of them. A quick scan of the blogosphere and you can see that everyone’s calling them out.

Alan Cohen counts 11 in total. Travis Jacobs has some knockabout fun with 7 of them in his much shared LinkedIn post. Charlie Alfred also sticks with the traditional 7, as does Dean Peters who ambitiously rewrites Dante’s Inferno to make his point.

But that’s 32 deadly sins already and I’ve only done one Google search.

So, as a kind of public service we’ve looked through a lot of them and tried to pick out some of the best of the worst - the most persistent, the most pressing and the most pertinent sins that dog every developers’ footsteps.

7 of the worst: deadly sins of the product development process:

1. PPP. That’s a technical term. It means P*** Poor Planning 

We can all be guilty of this. The impulse to roll up your sleeves and get stuck in might be what marks out passionate developers and entrepreneurs, but when it comes to a complex development process, skipping or skimping on the planning part invariably leads to disaster.

A formal plan is what helps keep you on track, it’s what stops you from disappearing permanently down rabbit holes, it’s what defines the objectives and parameters of a project and helps you deliver against them. As Alan Cohen points out, these plans will inevitably fall apart, change and reshape themselves as you go along. However, their existence as a baseline for your projects’ deliverables and the procedures you adopt to validate and deliver against them are what counts. Never forget the words of General Eisenhower:

“Plans are worthless, but planning is everything.”

2. Developing something the market doesn’t want

This point is related to the one above, but it’s still amazing how many products are built to fulfil a need that doesn’t exist. In fact, as CB insights discovered - 42% of startups that went bust, failed because there was “no market need” for what they were making. Not doing your research properly and starting work before you have identified who might actually want to buy or use your product, is a recipe for disaster.

But, remember, there’s no such thing as a bad idea. Except Clairol’s Touch ofYoghurt Shampoo range. That was a bad idea.

3. Being late

We’ve said it before, lateness screws everything up. It annoys clients. It costs you business. It has a knock on effect with other projects. Lateness is often a function of a chaotic and siloed development process. It’s exacerbated by a scattered and ill-defined document management strategy. If no one can locate the Functional Requirements or find that elusive email with the client’s latest feedback on it, your project is not going to advance quickly and without a hitch.

Why not just use Google Drive as a document management system?

And again, it all comes down to planning. We would argue that before you begin a project you need to make sure you have a flexible and robust way of collating, locating and collaborating on key pieces of documentation. And you need to make sure you have an agreed set of design and development processes to abide by. Reviewing your progress against requirements at key intervals will also help keep your dev team delivering on time and on budget.

4. Not addressing regulations

This is serious. If you’re developing for a highly regulated sector you need to take note of those regulations and plan to develop in accordance with them. In pharma or medical device development the stakes are high. Believing you can bluff your way through or imagining the rules don’t apply to you is the way to waste huge amounts of time, money and effort. Even making mistakes around the way CE markings are displayed or printed on packaging can delay a product getting to market and cost you a fortune to put right. You need to be bulletproof on this one.

5. Intransigence

Stroppy, difficult and resistant to change - is no way to talk about Project Managers. But who can blame them? Product development is costly and can be a lengthy process, by necessity it has to be a focused and highly efficient operation. But creating your specifications and ploughing on with projects, whilst ignoring changing circumstances and shifting requirements can result in an unsaleable or otherwise obsolete product.

Adopting a project management process like PRINCE2 which allows for a planned, phase-gated approach to dev is one way to make your process more flexible. Within PRINCE2 objectives and deliverables can be reviewed and tweaked to reflect new realities as a way of making better dev plans more suited to an agile age.

6. Perfectionism

You might call it the sin of pride. But the message is, you’ve got to know when it’s finished. The week before launch is no time to show off by adding that brilliant function you’ve thought of. Putting off a release as you polish and add bells and whistles is a terrible idea. Alan Cohen is particularly good on this point. The time for coming up with groundbreaking ideas, he says, is at the beginning of a process. We shouldn’t be aiming to ‘surprise’ the client at the end of a dev cycle with new stuff, we should be all about delivering fully functioning products in a timely and organised way.

7. Wanting something for nothing

This is every client. And it’s the worst. You’ve got to manage those expectations. As Travis Jacobs reminds us:

"You can have good, fast or cheap… Pick any two of these. But not all three"

Rising above it - the secret of a happy dev process

Everyone is always quick to point out other people’s failings, but you could argue being lazy, stubborn or greedy, is just part of human nature.

Calling it out in a product development process is one thing - but finding a way of working round these impulses and keeping a complex dev project on track is another.

In fact, all of these blogs identify one common problem with failing development cycles. The cardinal sin - the one that unleashes all these other disruptive behaviours, is a lack of adequate planning (see point 1).

Planning that properly defines deliverables and objectives, as well as the processes that you’ll follow to address them, seems to be the key to mitigating against the unholy mess of a dev project gone bad.