The Folly of Fail Fast ... We are here to SUCCEED MORE!

Fail Fast is a popular phrase beloved by entrepreneurs and wannabe companies as well as by large serious outfits trying to modify their big corporation DNA.

"Fail fast" or alternatively "fail fast succeed faster" or "fail forward" or even "fail better" is trying to tell us that it is better to get customers to experience your product and to learn from their feedback and from your mistakes. These conclusions drive a rapid review and improve phase where you can make the necessary changes. In many cases a worthy message.

The message is that this is preferable to lengthy planning,  development and refinement cycles in the office that don't involve the customer. Tirelessly looking for the ultimate product or ideal user experience. In many ways the idea is very similar to some of the Agile philosophy.

I am a huge believer in meeting the customer early and often and subscribe to much of the logic about doing, learning and improving, but, I have some issues with the fail fast slogan and even with some of the fail fast concept.

Let's deal with the trivial one first. There are many cases where it just doesn't work, I hope that Boeing and Ford for example don't embrace fail fast! 

However, in a broader sense on any business there are times when you can't afford to fail, because it ruins the positioning and reputation or because of budget. Let's accept that quick customer engagement is not an excuse for bad product design and implementation. Sure work quickly, cut red tape, be passionate about delivery but do the job right.

Now for my bigger issue, failure means getting it wrong and messing up. This is never a healthy, positive message it just sets the wrong tone and is a poisonous attitude to bring to work. It suggests that sloppy poor incompetence is suddenly acceptable. We can do it wrong and fix it in the next development cycle - no problem, nothing happened. 

We should remember that "perfection is the enemy of good" (Voltaire) or "Give them the third best to go on with; the second best comes too late, the best never comes" (Watson-Watt on Developing Radar during WWII)" These principles mean that we need to do be quick and achieve "enough" or in Agile terms MVP (Minimal Viable Product) so there is often no practical room for the dogged pursuit of perfection. We need to develop something that is at least fit for purpose. But we are not embracing failure as an option - just limited success.

When I googled the phase fail fast I can across a Wikipedia entry about system resilience. This is a more positive message, we need to build our product and we need to succeed and survive even if things aren't quite right.

Let's embrace efficient working practices, early customer engagement and let our people know that sometimes things do go wrong; so do your best to prevent this, but we understand and accept that it may happen. It is unfortunate and undesirable but failure is not our philosophy nor is it our core competence. There will be no blame game as long as you have tried very hard to succeed. We are a success orientated company.

Let's just Work Fast and Succeed More

WAC - Innovation & Standardisation

As telecom guys, we can’t let last week’s Mobile World Congress go by without a mention. One of the announcements was about the WAC (Wholesale Applications Community) standard. The WAC initiative was founded a year ago, has published v2.0 of the standard this week and plans v3.0 later in the year. A few telecom operators and suppliers have made some supportive announcements.

The basic idea of WAC is to allow developers a device agnostic way to bring their products to market and it will also improve operator involvement with application stores by allowing the operators to offer added value and services through their network. It is the latest in a series of initiatives to try to standardize this area of the telecom market.

Significantly Apple and Google are not members of WAC and are enjoying significant commercial success with their application stores. (In January Apple announced the 10 billionth app download.) They both choose to innovate aggressively, to create their own solution and to shun the standard approach.

The purpose of this blog is not to debate the merits of WAC, or its chance of success, but rather to consider the correct balance between standardization and innovation from the perspective of Product Management & Marketing.

Conventional wisdom (since the days of Henry Ford) has been that standardization rules. It simplifies the process, drives down costs and is at the core of mass production. WAC has the same objectives in mind – “WAC is …..dedicated to establishing a simple route to market for developers to expose their new applications to a customer base of over 3 billion customers.” It has been a brave PMM that has chosen non standard solutions – they increase cost, reduce the likelihood of success and are generally guaranteed to cause project delay.

However, Apple and Google have gone their own ways; and built their own solutions and created de-facto standards around their own eco-systems. Their strategy is that standardization should not be allowed to obstruct innovation. (There are many other technology examples in the past that followed the same basic strategy.)

However, also in the Telecom news was the agreement between Nokia and Microsoft. Behind the headline is the recognition that these two mega companies each with a strong tradition and proved track record of innovation have failed to deliver individually with Symbian (Nokia), MeeGo (Nokia & Intel) and Windows Phone 7 (MS). So clearly innovation even when driven by market leaders is no guarantee of success.

Often the process of standardization reduces innovation to the lowest common denominator to reach broad consensus and it can be driven by strong partisan commercial interests. In almost all cases it slows down the process – WAC is a good example. Compare the few early commitments with the number of devices and solutions in the Droid and Apple app stores.

Of course most PMM do not have the luxury of being able to create eco-systems on the scale of the app stores. However, we do need to balance standardization and innovation. Even today it is probably a wiser move to innovate in the context of app stores and not to rely on the WAC standard.

In many ways it is harder for the regular PMM; our product decisions are complex. We have to balance our need to differentiate with the need to be accepted via standardization. Our products are often expected to differentiate. We must also make some tough judgment calls on which are the correct standards and if it they are really appropriate for our product. If we are building a bleeding edge product we will often need to decide how we build a product that can be launched today yet is flexible to rapid change if a standard develops in a different direction.

Standardization is needed and should be supported, yet we need to remember when and how to innovate. Clever well executed innovation can be much faster to market and a strong differentiator and there is always the (remote) chance of creating a de facto standard!

When we manage our products we need to carefully evaluate what is our true ability to innovate and to generate product leadership and differentiation and when should we rely on standards and standardization. This is not a purely technical or tactical question. It is a strong commercial and strategic decision; just because a standard exists it does not mean that it will be commercially successful, nor that it is the correct product positioning for our product. The Telecom world has many examples of the standard that never caught on; Betamax is another example of the standard that didn’t bring commercial success.

However, to ignore an easy standard solution will ensure that we invest scarce resources in re-inventing the wheel rather than in creating the product we want in the time scale we need.

The balance between innovation and standardization is very difficult to achieve. Standards can simplify our product yet take time to evolve and are frequently not the best solution. On the other hand, wild innovation can produce an isolated, weak, expensive and late solution. However, without innovation it is very hard to differentiate at the product level. Finding the correct balance between innovation and standardization is The Art of Product Management & Marketing.

Product Management - The Longest Race - Part 2

In a recent blog (here) I discussed the product management and marketing lessons that could be learnt from the recent Nike 10K night race in Tel Aviv. I discussed the event planning (impressive and complex) and the event objectives (which were probably significantly more than just a fun run).

In this blog I will discuss some of the results of the event.

As a runner I can say I had an amazing time, and that on the whole this was an impressively run event.

However, the main question is what did Nike think? What KPI's did they set in advance for the event (number of runners? low number of problems? set up/clean up time? News minutes? Facebook group members?) Were their targets met? More importantly were the targets the correct ones or were they chasing the wrong things - were they were focused on their own issues and not on being customer centric?

During the course of the race itself there were other aspects of product management in action. Every once in a while there were music and water stations, we can consider them to be product features, helping the customers to enjoy the experience more, to engage with them - what will make them happy customers that will come back next year and recommend to their friends?

On the assumption that they plan to run a similar event next year, how, are they acquiring data and how are they planning to review and improve?

On the subject of next year we can consider product extension; will they feel the need to enhance the offering - perhaps by offering a shorter or longer version or by diversifying into a cycle race or triathlon? Perhaps there is a market for more than one event a year?

There were strict rules, we were all supposed to wear the official race shirt and run the course in an orderly manner. There were a few people who ran but I guess hadn't registered, and so ran in their own shirts and there were a few who wanted to stand-out and so ran in other shirts (last year's race etc) - on the whole this caused no problems to the runners. However, we can certainly view them in the context that the product was excellent, but, that it wasn't perfect - it was fit for purpose. Of course, since we mostly followed the rules, then we were complying with a certain standard, specification or protocol.

The race had a strict delivery schedule - it had to be ready on time and it had to work adequately well on the night. So part of the secret here is in team work and execution. The PM&M can have designed the perfect race, but if his project team didn't get the water in the runner's hands or publish the results then the product experience would have been irrevocably tarnished in the eyes of many of the customers.

So in conclusion I had a good run that evening and I believe that the experience was shared by the vast majority of the runners; I suspect that Nike felt that it was a success, but, that they have some points to improve or change in the next year. Overall this was a fine example of the craft of product management and marketing.

More importantly, I hope that by looking at an event that is outside of our day to day we can see the implications of strong product management leadership on all aspects of product design, management and marketing in general.

Creating a Product Road Map

“Follow the yellow brick road” - this is the instruction that Dorothy got in order to get to Emerald City.

Product managers are responsible for building the product’s yellow brick road – the Product Road Map.

The road map generally should normally be planned for a 3 year period at a high level and for 18 months in a more detailed manner.

Probably the most important starting point for the road map process is the outcome of the strategic business process of the company. This is a critically important process performed periodically (often annually) by the senior management of the company together with the marketing team and actually drives the entire company. When we start to create or update the road map the last version of the strategic process is a major input.

Often this will be replaced or supplemented by a product strategic process where we systematically look at all aspects of the product and the market and set key business objectives within the overall corporate strategic framework.

The road map process starts with information collection which should include the following:

• Market trends
• Regulatory trends
• Technology directions
• Competitive analysis
• Customer requirements and suggestions

In the next step we need to analyze what is the likely impact of each item on the product and what we can or should be do in order to give the best response to the probable impact. The best way is to create a product requirements matrix with all the needed activities, new features, platform changes, etc. and then to prioritize this list.

Having done that, we need to figure out what is required in the development of each element in the matrix. We must get the rough effort estimation and / or the budget needed. Now we have the information needed in order to make decisions and to create a road map release plan, if possible for a 3 year period, but not less than 18 months.

Needless to mention that during all the process described here we need to drive internal collaboration and buy in by involving and getting the opinions of many other groups from within the organization for example marketing, R&D, sales, operations and so on.

This is a cyclic process, since we need to do it again at least once or twice a year and adjust the road map if needed.

The decision whether to let our customers be involved in the road map or more precisely to what extent they should be involved is not an easy one. See this article for some of our thoughts in this area. Generally we need to make the product ready for market, but at the same time, we need to be careful not to let the road map drift in the direction of one or two (big) customers, but, is not in line with the general market direction.

We should be very careful when externalize the road map document since it is has some legal status as a kind of contract and as such we need to enter all the needed legal and financial disclosures.

Hopefully this road map will lead us to Emerald City.

In subsequent blogs we will look at ways to share the roadmap internally and externally, getting internal buy in and some of the methods available to do competitive analysis and technology reviews.