{"id":2006,"date":"2017-03-06T17:11:51","date_gmt":"2017-03-06T09:11:51","guid":{"rendered":"http:\/\/www.yibo.net\/?p=2006"},"modified":"2017-03-20T19:20:14","modified_gmt":"2017-03-20T11:20:14","slug":"root-causes-many-product-failures","status":"publish","type":"post","link":"https:\/\/www.yibo.net\/?p=2006","title":{"rendered":"10 Reasons of so many product failures"},"content":{"rendered":"

In this article I\u2019d like to discuss the root causes of so many product failures.<\/p>\n

I see the same basic way of working at the majority of companies, and I can\u2019t help but notice that this is not close to how the best companies actually work.<\/p>\n

Let me warn you that this discussion can be a little depressing, especially if it hits too close to home, so if that\u2019s the case, I\u2019ll ask you to hang in there.<\/p>\n

Let\u2019s start by walking through the process that the vast majority of companies still use to create products. \u00a0I\u2019ll try not to editorialize yet; let me first just describe the process:<\/p>\n

Everything starts with ideas. \u00a0In most companies, they\u2019re coming from execs or key stakeholders or business owners, or big customers (or prospective customers), but in any case there are always a whole bunch of things that different parts of the business need us to do.<\/p>\n

Now most companies want to prioritize those ideas into a roadmap, and they do this for two main reasons. \u00a0First, they want us to work on the most valuable things first, and second, they want to be able to predict when things will be ready.<\/p>\n

In order to do this, there is almost always some form of quarterly or annual planning session where the leaders consider the ideas and negotiate a product roadmap. But in order to prioritize, they first need some form of a business case for each item.<\/p>\n

Some companies do formal business cases, and some are informal, but either way it boils down to the need to know two things about each idea: 1) how much money will it make? and 2) how much money or time will it cost? \u00a0This info is then used to come up with the roadmap, usually for the next quarter but sometimes as much as a year out.<\/p>\n

At this point the product and technology organization has its marching orders, and they typically work the items from the highest priority on down.<\/p>\n

Once an idea makes it to the top of the list, the first thing that\u2019s done is for a product manager to talk to the stakeholders and flesh the idea out and come up with a set of \u201crequirements.\u201d<\/p>\n

These might be user stories or they might be more like some form of a functional spec but it\u2019s purpose is to communicate with the designers and engineers what needs to be built.<\/p>\n

Once the requirements are gathered up, the user experience design team (assuming the company has such a team), is asked to provide the interaction design, the visual design, and in cases of physical devices, the industrial design.<\/p>\n

Finally the requirements and design specs make it to engineers. \u00a0This is usually where Agile finally enters the picture.<\/p>\n

Anyway, the engineers will typically break up the work into a set of iterations \u2013 called \u201csprints\u201d in the Scrum process. \u00a0So maybe it takes 1-3 sprints to build out the idea.<\/p>\n

Hopefully the QA testing is part of those sprints, but if not, the QA team will follow this up with some testing to make sure the new idea works as advertised, and also doesn\u2019t introduce other problems (known as regressions)<\/p>\n

Once we get the green light from QA, the new idea is finally deployed to actual customers.<\/p>\n

In the vast majority of companies that I first meet, large and small, this is essentially how they work, and have worked, for many years. \u00a0Yet these same companies consistently complain about the\u00a0lack of innovation and the very long time it takes to make it from idea to customer\u2019s hands.<\/p>\n

You might recognize that while I mentioned Agile, and while almost everyone today claims to be Agile, what I\u2019ve just described is very much a Waterfall process. \u00a0In fairness to the engineers, they\u2019re typically doing about as much Agile as they can given the broader Waterfall context.<\/p>\n

\"\"<\/a><\/p>\n

OK, so that may be what most teams do, but why is that necessarily the reason for so many problems?<\/p>\n

What I want to do now is to connect the dots for you to show you why this very common way of working is actually responsible for most failed product efforts.<\/p>\n

Now I could literally talk all day long about the problems with this process, but what I\u2019m going to do here is share what I think are the \u201ctop 10\u201d most serious problems with this way of working.\u00a0 To be clear, I\u2019m arguing that all ten of these are very serious issues, any one of which could derail a team, but many companies actually have most or even all of these problems.<\/p>\n

1. Let\u2019s start at the top \u2013 the source of ideas. \u00a0<\/strong>This model leads to sales-driven specials, and stakeholder-driven products. \u00a0Lots more to come on this key topic, but for now let me just say that this is not the source of our best product ideas. \u00a0Another consequence of this approach is the lack of empowerment of the teams \u2013 in this model they\u2019re just there to implement. \u00a0Mercenaries.<\/p>\n

2. Next let\u2019s talk about the fatal flaw in these business cases. \u00a0Now to be clear, I\u2019m actually in favor of doing business cases, at least for ideas that need a larger investment. \u00a0But the way most companies do them, at this stage, in order to come up with a prioritized roadmap, is truly ridiculous. Here\u2019s why. Remember those two key inputs to every business case? \u00a0How much money you\u2019ll make, and how much it will cost? \u00a0Well, the cold truth is that at this stage, we have no clue on either of these, and we can\u2019t know.<\/p>\n

We can\u2019t know how much money we\u2019ll make because that depends hugely on how good the solution turns out to be. \u00a0If the team does an excellent job, this could be wildly successful and literally change the course of the company. \u00a0On the other hand, the truth is that many product ideas end up making absolutely nothing. \u00a0And that\u2019s not an exaggeration for effect. \u00a0Literally nothing. \u00a0In any case, one of the most critical lessons in product is knowing what we can\u2019t know, and we just can\u2019t know at this stage how much money we\u2019ll make.<\/p>\n

Likewise, we have no idea what it will cost to build. \u00a0Without knowing the actual solution, this is extremely hard for engineering to predict. \u00a0Most experienced engineers will refuse to even give an estimate at this stage, but some are pressured into the old \u201ct-shirt sizing\u201d compromise \u2013 just let us know if this is \u201cSmall, Medium, Large and Extra Large.\u201d<\/p>\n

But company\u2019s really want those prioritized roadmaps, and in order to get one they need some kind of system to rate the ideas, so people play the business case game.<\/p>\n

3. An even bigger issue comes next. \u00a0Companies get very excited about their roadmaps. \u00a0\u00a0I\u2019ve seen countless roadmaps and the vast majority of them are essentially prioritized lists of features. \u00a0Marketing needs this feature for a campaign. \u00a0Sales needs this feature for a new customer. Someone wants a PayPal integration. \u00a0You get the idea.<\/p>\n

But here\u2019s the problem, and it\u2019s maybe the biggest problem of all. \u00a0I call this the \u201ctwo inconvenient truths about product.\u201d<\/p>\n

The first truth is that at least half of our ideas are just not going to work. \u00a0There are many reasons for an idea to not work out. \u00a0The most common is that the customers just aren\u2019t as excited about this idea as we are. \u00a0So they choose not to use it. \u00a0Sometimes they want to use it, but they try it out and it\u2019s so complicated that it\u2019s simply more trouble than it\u2019s worth, which ends up as the same result \u2013 the users don\u2019t choose to use it. Sometimes the issue is that the customers would love it but it turns out to be much more involved to build than we thought, and we decide we simply can\u2019t afford the time and money to actually deliver.<\/p>\n

So I promise you that at least half the ideas on your roadmap are not going to deliver what you hope. \u00a0By the way, the really good teams assume that at least three quarters of the ideas won\u2019t perform like we hope.<\/strong><\/p>\n

If that\u2019s not bad enough, the second 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 actually delivers the necessary business value. \u00a0We call that \u201ctime to money.\u201d<\/p>\n

One of the most important things about product that I\u2019ve learned is that there is simply no escaping these truths, no matter how smart you might be. \u00a0And I\u2019ve had the good fortune to work with many truly exceptional product teams. \u00a0The real difference is how you deal with these truths.<\/p>\n

4. Next let\u2019s talk about the role of product in this model.<\/strong> \u00a0In fact, we wouldn\u2019t even really call this role product at all. \u00a0It\u2019s really a form of project management. \u00a0In this model it\u2019s more about gathering requirements and documenting them\u00a0for engineers. \u00a0At this point let me just say that this is 180 degrees away from modern product management.<\/p>\n

5. It\u2019s a similar story with the role of design. \u00a0It\u2019s way too late in the game to get the real value of design, and mostly what\u2019s being done is what we call the \u201clipstick on the pig\u201d model.<\/strong> \u00a0The damage has already been done, and now we\u2019re just trying to put a coat of paint on the mess. \u00a0The UX designers know this is not good, but they try to make it look as nice and consistent as they can.<\/p>\n

6. Maybe the biggest missed opportunity in this model, is the fact that engineering gets brought in way too late. We say if you\u2019re just using your engineers to code, you\u2019re only getting about half their value. \u00a0The little secret in product is that engineers are typically the best single source of innovation,<\/strong> yet they are not even invited to the party in this process.<\/p>\n

7. Not only is engineering brought in way too late, but the principles and key benefits of Agile enter the picture far too late. \u00a0Teams using Agile in this way are getting maybe 20% of the actual value and potential of Agile methods. \u00a0What you\u2019re really seeing is Agile for delivery but the rest of the organization and context is anything but agile.<\/strong><\/p>\n

8. This entire process is very project-centric.<\/strong> \u00a0The company usually funds projects, staffs projects, and pushes these projects through the organization and finally launches projects. \u00a0Unfortunately, projects are output and product is all about outcome. This process predictably leads to orphaned projects. \u00a0Yes, something was finally released but it doesn\u2019t meet its objectives so what really was the point? \u00a0In any case, it\u2019s a serious problem and not close to how we need to build products.<\/p>\n

9. The biggest flaw of the old Waterfall process has always been, and remains, that all the risk is at the end.<\/strong> \u00a0This means that customer validation happens way too late.<\/p>\n

You\u2019ve hopefully heard of Lean Startup methods, which are very much at the heart of the alternative. \u00a0The key principle is to reduce waste, and one of the biggest forms of waste is to design, build, test and deploy a feature or product only to find out it is not what was needed. \u00a0The irony is that many teams believe they\u2019re applying lean principles, yet they follow this basic process I\u2019ve just described. \u00a0And then I point out to them that they are actually trying out ideas in one of the the most expensive, slowest ways we know.<\/p>\n

10. \u00a0Finally, while we\u2019re busy doing this process and wasting our time and money, the biggest loss of all usually turns out to be the opportunity cost of what the organization could have and should have been doing instead. \u00a0We can\u2019t get that time or money back.<\/strong><\/p>\n

To me it\u2019s no surprise that so many companies spend so much time and money and get so little in return. \u00a0I warned you this could be depressing.<\/p>\n

The good news is that I promise you that the best teams operate nothing like what I\u2019ve just described.<\/p>\n

I have written many articles about the various aspects of how the best teams work. \u00a0Product Discovery is how we come up with winning solutions to the problems we are attacking. \u00a0Discovery is an active and ongoing collaboration between product, user experience design, and engineering. Continuous Discovery and Continuous Delivery happen in parallel. \u00a0Features on roadmaps (output) are replaced by business problems to be solved (outcome). \u00a0The goal is product\/market fit.<\/strong><\/p>\n

If your company is still running this old and long-obsolete process, then hopefully you can shine a light on this and start the transition to the future. \u00a0And hopefully you\u2019ll do this before you find yourself disrupted by a startup or competitor that is able to move much faster and more effectively than you can.<\/p>\n

The article is from:http:\/\/www.svpg.com\/product-fail,writed by\u00a0Marty Cagan.<\/p>\n","protected":false},"excerpt":{"rendered":"

In this article I\u2019d like to discuss the root causes of …<\/p>\n","protected":false},"author":3,"featured_media":2009,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[137,138,136],"jetpack_featured_media_url":"https:\/\/www.yibo.net\/wp-content\/uploads\/2017\/03\/45e281b51244a05f3d581ddfd8acc456.jpg","_links":{"self":[{"href":"https:\/\/www.yibo.net\/index.php?rest_route=\/wp\/v2\/posts\/2006"}],"collection":[{"href":"https:\/\/www.yibo.net\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.yibo.net\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.yibo.net\/index.php?rest_route=\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/www.yibo.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=2006"}],"version-history":[{"count":2,"href":"https:\/\/www.yibo.net\/index.php?rest_route=\/wp\/v2\/posts\/2006\/revisions"}],"predecessor-version":[{"id":2012,"href":"https:\/\/www.yibo.net\/index.php?rest_route=\/wp\/v2\/posts\/2006\/revisions\/2012"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.yibo.net\/index.php?rest_route=\/wp\/v2\/media\/2009"}],"wp:attachment":[{"href":"https:\/\/www.yibo.net\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=2006"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.yibo.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=2006"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.yibo.net\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=2006"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}