I shared the team’s mistakes with everyone, then this happened…

I shared the team’s mistakes with everyone, then this happened…

A few years ago, I led a product development effort at an enterprise. We were constantly experimenting, so had our fair share of wins and failures. But I had the feeling that we weren’t learning from mistakes quickly enough.

Large organisations maintain risk registers, which usually keep details of risks and issues. We also had a risk register, but it was being treated as one of those documents created for the sake of documentation.

Frustrated, I decided to put a poster on the wall with the title “Failure log”.

Why the heck a failure log?

The team reacted differently to the failure log. Some were amused, some confused, and some annoyed.

The annoyed ones saw this as exposing their weaknesses.

The confused ones didn’t know how showcasing our mistakes was going to help the project.

Others were happy that we were taking an initiative that could not only build psychological safety, but could also help us learn from our mistakes.

My challenge was that the organisation was not very mature. It was very much a command and control environment, so having the courage to publicly admit you’d made a mistake was a bold move, and to some extent a risk.

It was a risk because the board and the management team had invested heavily in the program and they were watching our progress very carefully. It was quite possible to face unintended consequences of making mistakes. In other words, it could have been a career-limiting – or perhaps even career-killing – move.

Luckily, the Chief Product Officer I worked with was progressively minded. He encouraged and supported experiments. Plus, the Program Director and I had become friends and she supported everything I did. Both could understand my vision and wanted to be part of it.

We were like a start-up within a traditionally managed enterprise.

Many of the team members, including the Product Leads and the Innovation Manager, were itching to do more and my bold step encouraged almost everyone to step up and forward.

I started adding smaller mistakes and things on that poster that could have been improved.

The Blunder!

And then one day… it happened!

A team member mistakenly sent a test email to hundreds of customers. It was a PR and Communications disaster.

You may be wondering why a test web page was connected with a production database?

The web page was built for a fake door experiment and the idea was to expose a very small number of customers to that page.

We got through that issue… but the question around recording that mistake on the Failure Log felt almost as tough.

The team was divided on sharing an embarrassing mistake with everyone else. Specifically in an environment where we were expected to have Gantt charts, detailed project plans, roadmaps, scripted test cases, and God knows what else.

So, what did we do about sharing the mistake?

After a bit of discussion within the team, we decided to include the mistake on the Failure Log because that was the right thing to do. There was a consensus about being congruent.

What happened after taking that major step?

I was sacked… right?

No. Nothing major happened at all. We were warned to be more diligent in future. That’s it. I thank my lucky stars for that.

Lessons that I learned:

But something did happen that was major for me:

  • The team became bolder
  • The experiments we quietly discussed earlier turned into open discussions
  • More items appeared on the Failure log, which by now had become the learning log
  • More and more visitors from other departments wanted to learn from us
  • And the best of all, the cohesion and collaboration among team members (as well as with the management team) improved

Taking a bold step, and then taking another courageous step on top of that, taught us many lessons and made us a great team. We delivered value to customers, and we were more open about our outcomes. Best of all, the tea cohesion improved.

I can’t ignore the fact that the senior folks I worked with made it easier for me to take bolder steps. If executives aren’t supportive, then forget about experimenting with new ideas.

The failure log was an experiment that could have gone in any direction. It could have become a political mess, or quietly died from lack of interest.

Users don’t know what they want, and we don’t know our users!

Users don’t know what they want, and we don’t know our users!

I was speaking with a friend yesterday who happens to be a senior leader in a big 4 bank in Australia. He told me that he recently rubbished a new feature that a group of tech and prod people brought to him for improving frontline staff’s work.

He wasn’t pleased that the group didn’t know what the staff on the frontline did. So, he asked them to spend a day in the bank’s branch and observe what the staff did.

The group returned with their observations and admitted that their idea was faulty.

It seems that product and tech teams don’t invest enough time and effort in learning what their users do, or how they perform their jobs.

Asking users what they want isn’t a good approach:

Don’t ask users what they want. Users don’t know what they want, so they ‘dictate’ what they desire.

You should have heard the quote attributed to Henry Ford where he says, “If I had asked them what they want, they would have said a faster horse!”

Horse cart users would have desired for faster and healthier horses, and more comfortable carts. 

So, Instead of asking users what they want and then jumping right on doing that, we should:

– ask them for their pain points
– get their insights and learn from those
– ‘explore’ rather than ‘gather’ requirements

So what do we do if not ask users?

It is true that often users are served features or products that aren’t useful for them. Possibly because people who build those products never find out how users do what they do. That’s another problem because of which we see so may rubbish products in the market.

A while ago, my doctor (GP) explained a similar situation to me. She was struggling to use the software that the health practice had recently bought from a software firm.

Her comment was, ”They built this software for doctors without understanding what doctors do and how they might use this software.” Fair enough!

Not engaging with potential customers or users is one of the biggest shortcomings of product development. An even bigger problem is not knowing what the users actually do.

Knowing what a user does provides deeper insights into their work. Those insights can significantly inform and influence the development work that the product teams undertake.

Why innovation almost always results from unconventional methods

Why innovation almost always results from unconventional methods

 

 

 If you look closely, the process that Henry Ford used for devising Assembly Line (the process that introduced mass production to the world), was itself a Lean and Agile process.

When Ford was working and competing with other niche car manufacturers, he didn’t copy the model that everyone else was using. That is, he didn’t rely completely on suppliers which were manufacturing vehicle parts as individual units. The parts that these suppliers produced, were not always identical. Assemblers at the factories had to mold them using hammers or mallets so that they fit the vehicle. Instead, Ford kept experimenting to achieve the outcomes he was looking for. His experimentation included changing almost all aspects of the process, often one at a time. His whole approach was iterative and incremental.

Here is an  example of what he did and how. 

Assembly station related experiment:

In order to reduce timing of building cars, Ford designed assembly stations.

At first, both the assembly station and the assembler were stationery.

Cycle time 514 minute.

Ford wanted to improve on this time and he decided to make changes. As a result, the assemblers were now moving station to station within the factory. That meant that the stations remained stationery.

The cycle time now reduced to 2.4 minute.

Isn’t that astonishing? A lot of people would be elated with such a feat and would just stop any further improvement. In the actual fact, stopping is even a far cry, most will not even agree that any more improvement would be possible.

The next change that Ford made was to keeping assemblers stationery and turning assembling stations into moving platforms, which became known as the assembly line.

The cycle time now was 1.3 minute. 

The point is, whatever you are attempting to do, check if that encompasses experimentation, exploration, critical thinking, pivoting, learning (even from failures) and iterating.

Setting up innovation hubs, centre of excellences and sloppily copying & applying labels has never made any organisation innovative or progressive. If you’re in a position of power, empower others and build an innovation culture. If you’re not in a position to make large scale changes, at least change the way how you do things.