Product management Archives

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

by Raj | Feb 14, 2022 | Agile, Culture, Delivery Leading, Product development, Product management | 0 comments

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!

by Raj | Feb 10, 2022 | Delivery Leading, Product development, Product management, Software Development | 0 comments

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.

How to use SIPOC for mapping Agile delivery process

by Raj | Jul 19, 2020 | Agile, Delivery Leading, Product management, Project management | 0 comments

There are many process mapping tools available and SIPOC is one of them that delivery leaders can use for their Agile initiatives. SIPOC traditionally has been used in Lean Six Sigma process improvement projects.

“But Lean Six Sigma isn’t Agile!”, You may exclaim.

Let’s not get into the debate of what is and what isn’t. As good Agile delivery leaders we want to have more than one tool in our toolbox and this might be one of those tools. For example, finding a right starting point for a new initiative can be hard for many delivery leaders and we could use SIPOC for that purpose. You can also use it early in the project to create alignment among your team and stakeholders.

Another important thing to remember is that we can learn tremendously from other disciplines. If you haven’t yet, then I strongly recommend that you read “Range: How Generalists Triumph in a Specialized World“. The author, “David Epstein shows that the way to excel is by sampling widely, gaining a breadth of experiences, taking detours, experimenting relentlessly, juggling many interests – in other words, by developing range”. (Excerpt in italics taken from the book introduction on Amazon.com).

By learning tools and techniques outside from our own craft, and sometimes outside from our profession, we learn more about ourselves.

What is SIPOC:

Sipoc is a process mapping and definition tool. The letters stand for: Suppliers, Inputs, Process, Outputs, Customers. These are the heuristics that guide us for defining a process at the commencement of a project or an initiative. You can also use it for process improvement activities (continuous improvement must be an ongoing goal for you).

SIPOC is like a customer journey map because both define a process while keeping the customer in mind. SIPOC compels you to think through the whole journey of a product or a process, beginning from a supplier to the customer. Without thinking in terms of suppliers, their inputs to a process, the steps of your process, the outputs that your customers may get, you might miss important details.

A key difference between SIPOC and Journey mapping is that a journey map focuses entirely on a customer’s experience, while a SIPOC focuses on an end to end process. This may also appear like a drawback of SIPOC that it talks about the customer last.

Another concept that is quite close to SIPOC is Value Stream Mapping (VSM). Since VSM is a Lean concept, it is used more often by Agile teams than other concepts. However, as I previously suggested, there is nothing wrong in having another tool in your toolbox.

Why use it?

Like any other mapping tool, the strength of SIPOC lies in its visualisation and simplicity. If a process is written in a thick, multi-page document, the chances are no one would read that and the creator will not receive any feedback. Since SIPOC can be created on an online tool like Whiteboardfox, or in-person using an A3 page or using sticky notes, it is far easier to get feedback.

Another reason for starting with a SIPOC instead of jumping straight into a process mapping exercise is that it enables teams to think beyond the process. When you use it, you have very little chance of missing on high-level process steps and the scope inclusions and exclusions.

Moreover, SIPOC provides a structured and simple way to convey and brainstorm a process.

Who should be involved in the process?

Ideally, the team members that will support your initiative and work on it should be involved in the process mapping exercise. Any stakeholders that have interest in your initiative should also participate in this process. That is, you should ensure that the process does not miss inputs from key people.

How to create a SIPOC diagram?

SIPOC is an easy to use tool. It is often presented in a tabular or diagrammatic form. Your starting point is to draw five items which are Suppliers, Inputs, Process, Outputs and Customers.

Supplier: Make a list of everyone or everything that might provide an input in your process.

A supplier can be those people or groups that provide inputs into the process. For example, a supplier can be a stakeholder or a sponsor of an initiative. A supplier can also be an upstream system or a process and a customer might be a downstream process or system. Think from provider- receiver or cause-effect point of view.

Process: Begin with a starting point of a process. Your process might depend on the inputs provided by the suppliers. Once you have a starting point, describe the key steps till the end. With having clear starting and end points, it would be easier for you to complete the full chart.

Output: An output is what we produce or deliver as information, service or a product that our customer uses.

Customer: People / groups that receive and use the output of the process. A customer benefits from the process.

Benefits of using SIPOC:

A SIPOC diagram is easier to create. It allows collaboration between various groups and helps us create a shared-understanding. Since many people provide their inputs, they also feel ownership. Of the initiative.

Some of the other benefits of SIPOC are:

– it provides a high level overview of the process

– it helps us define the stakeholders (suppliers and customers)

– it define and clarifies the scope and boundaries of a process, and most importantly

– it helps a team to understand how their process serve the customer

So, you now have another tool in your toolbox. Let me know if you find a use of this tool.

Additional Reading:

For familiarising youtrself on such topics, Wikipedia is always a good starting point. But don’t stop there. Continue exploring more if you find a topic useful.

https://en.wikipedia.org/wiki/SIPOC

SIPOC definition on ASQ