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

Get the Design Right Before the Start of Development

We are currently working on a data intensive product. We have a great team - top class developers and team lead, a great system architect and I hope a pretty good product manager. The requirements are well understood and we received a well researched specification from the project sponsor. We are working using Agile and although this is a start from nothing project we produced some impressive user flows with demonstrable value even in the first sprint.

So as the product guy I am very happy and keen to demo the product to anybody and everybody.

There is, however, a problem. At almost every Discovery meeting, after every daily and at working meetings in between we change the data model, just a bit to tweak it; (almost two sprints into the development.) I have tried to analyse the situation and reached several conclusions. I don't think that we are tweaking it just for the pursuit of perfection. Almost all the changes are because there were some soft areas in the requirements and because the model isn't yet fully functional. I am sure that in another couple of weeks we will have resolved most of the issues and things will reach some equilibrium.

Secondly I think that the discovery team and developers are so switched on and involved that we are really working the topic. We get involved and we have opinions (and the problems are quite involved and tricky.)

As an aside; this intensive (re-)design method leads to uncertainty, the changes are so intense (and actually quite subtle) that the documentation is less than perfect. Partial explanation is found in different user stories with open editing rights. This makes things just a bit harder for the team. There is plenty of readjusting and rewriting.

My last conclusion is that in this project we needed a more traditional approach that involved a full system design that was analysed, debated over and clarified for a (hopefully short) period of time before the first line of code was written.

A stable well defined design at the outset would have saved us a lot of time, debate and on the fly design and development. It would also have improved the communication and stability through better design documentation.  I am sure that we would have missed a few points, but then the Agile method would have allowed relatively small and painless corrections.

I think that there are many products where more forethought before starting the sprints will lead to more efficient implementation (and necessary corrections) in the development phase, It isn't always easy to do this - often the requirements are still in development or there is pressure to start work, and perhaps in subsequent releases where the changes maybe quite small relatively it isn't even necessary. However, I think that it is a valuable question to ask when initiating product development can we improve the design before we start work? There is a subtle balance to be achieved between over design/slow customer interaction and impulsive coding/multiple revisions.

Which way out? - The Importance of Exit Criteria

One of my fundamental criteria for starting a new product release is being able to define the Exit Criteria.

As a rule of thumb it is being able to answer the following five simple questions with accurate and complete answers (the questions are simple - the answers less so ...)

1. WHAT? - What are we building? What the key features and product values that the release will deliver?
2. WHY? - What are the key benefits that the customer will derive from the product when it is released? What are the values and advantages that the release will bring to the product family/company?
3. WHO? - Who needs the product? If this is a release for the market then define the customer - specific accounts or profile the type of user that the product is targeting. Also state who will help with the necessary integrations, GTM efforts and other internal stakeholders. If this is an internal development effort then who is the internal sponsor and who is tasked with supporting the integration and deployment.
4. WHERE? - Where should the product be delivered? Describe the internal or external deployment scenarios and any pre-requisites that will make the difference between a successful launch and failed one.
5. WHEN? - What is the timeline for this release? When must the product be in the marketplace or delivered internally? 

Once defined these criteria should be critically analysed to ensure that they are coherent and meet the SMART (Specific, Measurable, Achievable, Relevant & Time-bound) criteria. Will they meet the overall objectives? Will the product as defined meet customer expectations? Is the product definition correct? Can it be delivered in the time-available? Is the target customer the correct one to achieve the overall aims? Is the target environment feasible. Answering these questions will often force a rethink and changes, but should result in a clear definition of expectations. The entire team can adopt the final definition adding purpose and clarity. It is also critical in managing any changes that maybe needed during development


Overall the Five W's set out to define what does the product need to do, by when in order to make somebody very happy?

In my experience this is an iterative process, but, answering these five simple questions adds significant clarity to the product objectives and can make the difference between a successful product and a poor executed product that takes significantly more time and resources to develop and then fails to deliver most of what was expected.

Being Customer Passionate

Customer service with passion makes a difference.  You can feel it. You know it when you get it.

An example -  my company recently changed cleaning contractors; you know the people in blue uniforms who sweep and clean and who seem to change with alarming frequency . (A small digression;  they make a huge difference to our lives and you see them every day so be friendly and grateful to them a quick hello is really appreciated.)

The new team are pleasant enough as people and seem to be full of activity doing the regular cleaning stuff. They sweep, their managers buzz around and they all fill in the standard inspection forms. So seemingly all is well. However, actually things are just almost OK, but are certainly not to the right standard. The floors don't quite sparkle, often there are shortages of paper and unexpected messes seem to take a long time to be cleared.

On our floor the old contractors had a super team. As far as I could understand (they were immigrants and we didn't really have a common language) they were actually a husband & wife team.  

What is for certain is that the worked very hard and cared for our office just like it was their own home. They did extra inspections and made sure that everything was just right or even better. I am sure that our toilets and kitchen were as clean as in their home. They cared- actually they really cared and they had pride when you showed appreciation. Some other company now has their services and is very lucky - Anna & Anatoly come back we miss you!

They were true cleaning professionals and worked from the heart and it really showed. The new team just do their job and that also really shows. We all appreciate people who are customer passionate.

We need that professional passion in all our products - that is a difference that the customer notices. It is true differentiation.

The Value of Business Value

Business Value is often the holy grail of Product Management (and rightly so) especially when working in Agile.

Business value is genuinely very important; product managers are tasked with building products that offer some real value to somebody. Business values impact almost everything that we do with our product - its positioning, its go to market, its roadmap and its customer centric focus. These core elements of the art of product management are derived from and driven by the business values.

Classically we build things that people want to buy, advancing the business plan of our company. In other cases we may be trying to build infrastructure or experimenting with some novel ideas. However, in almost all cases we can define the objective with business value even if it is a stage or more removed from an actual sale to a customer. I plan to explore business value in these indirect cases in a future post.

So given that business value is one of, if not the primary objective of our professional lives it seems surprising how little attention many of us pay to the business value. Sure we read and write documents with some lip service to the business value. When we do a kick-off meeting we feel forced to generate a couple of statements on the subject and every so on a senior manager will feel the need to talk to even more senior people and have a mini crisis trying to generate a set of business values across all the products that they sponsor. It is possible that this is mainly a feature of big organisations; but my suspicion is that it is a common feature. It is more fun to build and design than to make bold declarations of future business value.

The crux of the issue is that it is really very important and on the critical path of everything that we do. If you are lucky enough to be constantly customer facing then you probably have a pitch maybe even several for different segments, but for the rest of us it is rarely on the agenda.

So here is an idea that I plan to put into action tomorrow - to have a slide deck or excel or some other file with every product that I manage together with its business value. So far, relatively easy, now for the hard part -  to try to keep it updated - say four times a quarter. At most reviews I think it will just be a critical read through and add the review date; but every so often things will change.

I think that this exercise will help in a few ways -

• We will really understand why we are building the product
• We will be able to remain true to the objective and not get inadvertently side-tracked in the natural drift of a dynamic product
• We will make any necessary changes actively after due thought 
• Of course finally we will always be able to provide answers to anybody who needs to know right now