Why is Product Thinking important?

Dec 2, 2021| Chisara Nwabara

This post is the second in a series on Product Thinking:

• What is a Product Thinking mindset?
• Product Thinking in practice

EngineerBetter is known as a source of knowledge for helping back-end engineering teams deliver platform-based technology solutions to their consumers, i.e. product and delivery teams. What we’ve learned over the years is that because these internal teams are often treated as support or supplemental functions, the same level of thought and care does not go into how they are positioned

We’ve spent some time discussing what a Product Thinking mindset is, as well as a bit on why in the first article of this series. Now, let’s discuss why it matters in greater detail. To answer this question, there are three key points worth highlighting.

“Speed at the cost of productivity and efficiency is not progress.”

Chisa Nwabara, EngineerBetter

Technology is constantly changing and evolving. Oftentimes we’ve observed that in order to maintain a perceived speed of pace, companies and teams end up sacrificing more than they realise in the form of quality and team performance.

When this happens, productivity can be so affected and changed that one does not realise just how much efficiency is sacrificed. Typically, a desire to go quickly surpasses efficiency to the point that it ends up costing organisations an exponentially larger amount to sustain inefficient and unsustainable practices.

“If I had only one hour to solve a problem, I would spend up to two-thirds of that hour in attempting to define what the problem is.”

Head of Industrial Engineering, Yale University

Nell Derick Debevoise, writing for Forbes cites a similar quote attributed to Einstein. “The point he makes,” she goes on to say, “is important: preparation has great value to problem solving. And what is any task worth doing but a problem to be solved?”

When thinking about what success looks like, it’s important that we’re measuring the right things (or even taking measurements in the first place)… Ultimately, these teams are providing a service to their end-users who oftentimes are likely to be other developers or internal peers.

“Just because you’re not selling to a customer, doesn’t mean you don’t have users.”

Daniel Jones, EngineerBetter

The deliverables that teams produce are services, experiences, products…

These are teams that are tasked to deliver value to end users, but they may not have strong perspectives on how best to go about doing so, i.e. developers are not thought of as customers. There is little to no expertise on how best to prioritise internal backlogs. Most importantly, there is little guidance on how to validate that the platform-based decisions being made are solving the right problems

By solving these pain points, the odds are increased that organisations will create sustainable internal systems that lead to less waste, better feedback loops and more effective teams who are capable of producing value for customers.

We think this is important because…

Agile Methodologies and Product thinking are two peas in a pod!

Agile added a feedback loop between customer and developer, but despite this we still seem to spend so much time focusing on the tech and the solution, that we haven’t done enough to determine if the solution matches or solves the problem for our users in the first place. We forget that at the heart of tech advances, we’re ultimately trying to solve problems for people and add more value to their lives,

Product thinking used in conjunction with agile practices produces more effective teams who are able to deliver valuable outcomes as opposed to unverified outputs. We also tend to see an increase in transparency and accountability because we validate and provide reasoning for decisions that are made.

Like Agile, product thinking is rooted in healthy experimentation and hypothesis-driven approaches. This continuous learning means once you’ve identified and solved a problem, you can feed it back into your method with strong agile practices and continuous improvement, i.e. create more accuracy in your feedback loops which in turn produces better-vetted results.

What is the point of going fast in the wrong direction?

You can go as fast as you like, but if you’re building the wrong thing, you’re screwed anyway because no one will use it and chances are, a great deal of waste will be created in the process.

As previously mentioned, if agile is the vehicle you are traveling in, Product Thinking is the GPS navigation ensuring that you’re tracking in the right direction on your journey. Product Thinking captures and holds teams accountable to justifying the intent of their actions. In a space where work is justified and actions are intentional, less will happen without good reason.

A cautionary tale

EngineerBetter worked with a CTO who asked for help creating an effective software delivery practice and technology culture. Whilst performing this consultancy work, it became clear that the business was a ‘feature factory’ - the visionary CEO, who had willed this first-of-its-kind product into existence, was still dictating which features needed to be built. There were no success criteria associated with these features, nor any attempt to check that they were having a positive effect. If he woke up one morning with a new idea, it was suddenly the company’s top priority.

We identified this as a risk and implored the CTO to allow us to engage with the CEO to perform some executive coaching. The CEO needed to know that he had ’levelled up’ and was no longer building a product, but instead building the company that built the product. He needed to delegate product decisions to professionals, and most importantly validate that features had the desired outcomes. Without this, all the agility in the world would only help them deliver the wrong thing.

Our requests were repeatedly declined. “He’s not ready for that yet”, “we need to make improvements first before having that conversation.” We should have done a better job of convincing the customer that we could help.

Some months later, the CEO made a unilateral and fundamental change to the product without checking that it was what customers actually wanted. Customers felt cheated, left in their droves, and started a downward spiral that (combined with the COVID-19 pandemic) resulted in the company becoming insolvent.

Product thinking makes each feature a bet - if we spend X building Y, then we think we’ll see effect Z.

An organisation without product thinking turns itself into the bet - we’ll build whatever we think is the right thing, and if we’re wrong, we’ll go bust.

When teams are empowered to care about what they’re doing, it shows

So many morale and people issues have crept into the many of the delivery teams that we are later asked to help. Oftentimes, we find that the “people” aspect of our field is lost the moment we get to the teams doing the building. This directly affects how well those teams function and the things that they produce, as dysfunctional teams are unable to be as effective or productive as they could be.

Product thinking done well can lead to a reduction in blame culture because everyone owns the outcome and it no longer becomes about the individuals, but instead about the deliverables and their value to users. This also creates a sense of purpose because product delivery teams are informed and empowered around what they’re building as opposed to effectively building blind…

There’s nothing wrong with telling engineers why they’re doing what they’re doing and how their efforts produce value and directly affect the outcomes i.e. constructive channels of accountability via informed decisioning. There also should be nothing wrong with allowing them to ask questions so that they truly have access to the information they need to deliver the best outcomes possible.