Where product thinking really comes into play

There’s a scenario which many of us witness every now and then. A team in a room, looking at a virtual or physical backlog. Lots of stories, stacked up and scattered across column after column.

Some will be very big stories, not doable in a single sprint. Others will be smaller, but they are still there and together it looks like A LOT to do. Someone asks: “Hmmm, when are we supposed to finish everything again?”

Backlogs like this cause anxiety for team members, which is a killer for both human and team performance. Time is finite, and there needs to be constant prioritisation and re-prioritisation to make sure only the most important stories make it into sprints.

But how do we know what’s most important? Is it attacking the thing we know the least about? Starting with the easiest/best-understood piece of work? Following a technical sequence that gives us the perfect implementation? What project sponsors dictate? Or some other things that data tells us are problems or pain points?

Juggling these decisions is where product thinking comes into play.

Product thinking as a navigator

When organisations invest in technology, they want some benefits in return. These benefits can take many forms, like saving time and money, happier external and internal users, providing data to inform better decisions, complying with new rules or legislation, and so on.

Product thinking is the way to balance the decisions taken by a multidisciplinary team so they support the overarching goals and desired outcomes of the project. It is a painful, yet fun exercise to shuffle between user needs, the business’ often perceived realities, what’s technically possible, and team dynamics.

It works best when there’s lots of conversation happening in the team about the most effective compromise that still achieves the intended value.

Delivering value early and often

So product thinking is about building the right thing in the right way to achieve the outcomes we need. Taking a product approach means you can create value for the end-user or the business as early as one single sprint in.

It’s radical, but our aim should be creating value for users in every sprint. If we have to stop the project for whatever reason, we will still have created something that serves users at that particular point.

Only when we have delivered something of value, do we start getting a return on the organisation’s investment. It means the client can decide to move on and invest in solving another problem if they want to.

There is no certainty without measuring things

But how do we know when we’ve achieved the outcomes we need and it’s time to move on?

This is about data, research and observation. When a version of the software or a new process or policy is released, it is imperative that we track the impact it has.  We can only know if we’ve succeeded by observing how real people use things in the real world.

Product thinking is so heavily based on hitting outcomes and generating value that it can’t take place when user research doesn’t happen or metrics are not tracked. Good investment decisions cannot be justified without impact evaluation, and that’s true for digital interventions, like software, too.

Product thinking and user research are inseparable

That’s why user research and product thinking are inseparable disciplines.

We can’t know if we are realising our desired outcomes if we don’t look at what real data tells us. Product managers can’t take evidence-based decisions without the information generated by user research, and user researchers need to focus their efforts on the specific outcomes for a project.

This doesn’t mean that only product managers and user researchers can, and should, do product thinking. Everyone in the team needs to keep an eye on the question “why are we doing this work?”. But good product managers will rally people around common problems, outcomes and goals, and a vision. They will also coach the team to think in this way, leading by example.

Product management at dxw

At dxw, we’re not always able to put product managers in project teams. Clients sometimes have someone internally called a product or service manager that they believe is carrying out this role. However, they often turn out to be someone with very many other responsibilities which prevent them from doing it effectively.

We believe this has to change to successfully deliver the desired benefits for users and organisations. Product thinking is one of the fundamental pillars of agile; value released early, insights learned fast, reacting as quickly as possible, a focus on outcomes.

If you would like to discuss this further please get in touch, and stay tuned as we share more thoughts and progress!