10 Root Causes of Failed Product Effort.

Hello friends, It’s been a while since I didn’t write something here. I am currently working on stuff about material science which I will of course share with those interested and I am also continuing my work with CAD systemes as well. More about all that will follow here. I have a lot of engineering news to share, but you’ll see that later.

For now in this post I want to share with you a bit from my experience as design engineer and what I have learnt during the years. The main topic here is the following: Companies fail to deliver a great product. And here is WHY.

There might be many issues during a product development but I can say for sure that the failures in product effort which I highlight here are already confirmed to be present in any tech-company.

When we think of a new product, everythings starts with ideas. In most companies they’re coming from inside (executives or key stakeholders or business owners) or outside (current or prospective customers). Wherever the ideas originate, there are always a whole bunch of things that different parts of the business need us to do.

In the list that follows, I’m going to share what I’ve seen so far and I consider these to be the 10 biggest problems in designing a tech-product. All these problems are very serious issues, any one of which could derail a team. In general many companies have more than one or even all of these problems.

Reasons why Product  fail.

1. SOURCE OF IDEAS

This model leads to sales-driven specials and stakeholder-driven products.  Let’s say that this is not the source of our best product ideas. Another consequence of this approach is the lack of team empowerment. In this model, they’re just there to implement- they’re mercenaries. This is always due to weak people management. The best product teams need missionairies not mercenaries becasue missionaries are true believers in the vision and are commited to solving problems for their customers. In a dedicated product team, the team acts and feels a lot like a startup within the larger company and that must be very much the intention. So when that is not the case, then you are working at a company with incompentent managers.

Companies fail to deliver great products, always becasue they have incompetent managers and NEVER becasue of their engineers.

2. BUSINESS CASES

This is a fatal flow. To be honest I am personally in favor of doing business cases, at least for ideas that need a larger investment. But the way most companies do them at this stage to come up with a prioritized roadmap is truly ridiculous and here’s why:

Every business case always has 2 key inputs which must be addressed, namely:

How much money you’ll make? and How much it will cost?

Well, the cold, hard truth is that, at this stage we have no clue about either of these. In fact, we can’t know. We can’t know how much money we’ll make because that depends entirely on how good the solution turns out to be. If the team does an excellent job, this could be wildly successful and literally change the course of the company. The truth, however, is that many product ideas end up making absolutely nothing. And that’s not an exaggeration for effect. Literally nothing. (we know this from A/B testing). In any case, one of the most critical lessons in product is “knowing what we can’t know” and we just can’t know at this stage how much money we’ll  make. Likewise we have no idea what it will cost to build. Without knowing the actual solution, this is extremely hard for engineering to predict. Most esperienced engineers will refuse to even give an estimate at this stage, but some are pressured into the old t-shirt sizing compromise-just let us know if this is “small, medium, large or extra large”. But companies really want those prioritized roadmaps and to get one, they need some kind of system to rate the ideas. So people play the business case game.

3. PRODUCT ROADMAPS

So far I’ve seen countless roadmaps over the years and the vast majority of them are essentially prioritized lists of features and projects. Marketing needs this feature for a campaign. Sales needs this feature for a new customer. Someone wants a PayPal integration. You get the idea. But here’s the problem – maybe the biggest problem of all. It’s what I call the 2 inconvenient  truths about product.

The 1st truth is : that at least half of our ideas are just  not going to work. There are many reasons for an idea to not work out. The most common is that customers just aren’t as excited about this idea as we are. So they choose not to use it. Sometimes they want to use it and they try it out, but the product is so complicated that it’s simply more trouble than it’s worth, so users again choose not to use it. Sometimes the issue is that customers would love it, but it turns out to be much more involved to build than we thought and we decide we simply can’t afford the time and money required to deliver it.

So I promise you that at least half the ideas on your roadmap are not going to deliver what you hope. (By the way the really good teams assume that at least three quarters of the ideas won’t perform like they hope).

If that’s not bad enough, the 2nd inconvenient truth is: that even with the ideas that do prove to have potential, it typically takes several iterations to get the implementation of this idea to the point where it delivers the necessary business value. We call that time to money.

One of the most important things about product that I’ve learned is that there is simply no escaping these inconvenient truths, no matter how smart you might be. The real difference is how you deal with these truths.

4. THE ROLE OF PRODUCT MANAGEMENT 

In fact if we wouldn’t call this role product management – it’s really a form of project management. In this model, it’s more about gathering requirements and documenting them for engineers. At this point, let me say that this is 180 degrees away from the reality of modern tech product management. I’ve seen and even work with so many so called “Project Managers” which were supposed to guide and inspire the team to work on the vision but all what they did was to make sure they remain “Project Manager” and get the yearly bonus at the end of the year.

5. THE ROLE OF DESIGN

Mostly what’s being  done here is what we call the “lipstick on the pig” model. The damage has already been done and now we’re just trying to put a coat of paint on the mess. The UX designers know this is not good, but they try to make it look as nice and consistent as they can. The resposible for the failure is again the Product Manager becasue he don’t comunicate with the engineers. A good (design) engineer is always more techincal savvy that any manager, so in design engineering I would say from techincal point of view and engineer is more savvy that the product manager. Therefore communication with and empowering the design team is essential for a sucessful product.

6. ENGINEERING GETS BROUGHT IN THE WAY TOO LATE

We say if you’re just using your engineers to design, you’re only getting about half their value. The little secret in product is that engineers are typically the best single source of innovation; yet, they are not even invited to the party in this process.

7. THE PRINCIPLE AND KEY BENEFITS OF AGILE ENTER THE PICTURE FAR TOO LATE.

Teams using Agile in this way are getting maybe 20% of the actual value and potential of Agile methods. What you’re really seeing  is Agile for delivery, but the rest of the organization and context is anything but Agile, regardless if the product is a software or a hardware.

8. THE ENTIRE PROCESS IS VERY PROJECT-CENTRIC

The company usually funds projects, staffs projects, pushes through the organization and finally launches projects. Unfortunately projects are output and product is all about outcome. This process predictably leads to orphaned projects. Yes, sometimes was finally released, but it doesn’t meet its objectives, so what really was the point?. In any case, it’s a serious problem, and not close to how we need to build products.

9. CUSTOMER VALIDATION HAPPENS WAY TOO LATE

The key principle in Lean methods is to reduce waste, and one of the biggest forms of waste is to design, build, test and deploy a feature of product on an entirely new product only to find out it is not what was needed. The irony is that many teams believe they’re applying Lean principles, yet, they follow this basic process I’ve just described. And then I point out to them that they are trying out ideas in one of the most expensive, slowest ways we know.

10. OPPORTUNITY COST

While we’re busy doing this design process and wasting out time and money, the biggest lost of all usually turns out to be exactly the opportunity cost of what the organization could have and should have been doing instead. We can’t get that time or money back. It’s no surprise that so many companies spend so much time and money and get so little in return.

That being said, it’s critical that you have a deep understanding of exactly why your company needs to change how it works, if indeed, your company is working this way. The good news is I promise you that the best teams operate nothing like what I’ve just described.