Product development basics & 3 hints to increase chances of success with any team

In product development it seems to me that there is too much focus on labels and specific frameworks or methods. Regardless of how we get there, many seem to forget that the goal is always to build products that work. The goal is successful product development. 

Today I want to take a step back and ponder product development as a whole. I will try to explain what it means to me. I will also share the three things I focus on when working with a team. Focusing on those three have been great guidelines for me in successfully building products in the past. 

Let’s start with the basics.  

The Backlog is a bi-weekly newsletter about the undervalued and overlooked in modern product development. It covers product development, self organization, and productivity. I include methods, books, and write about my own experience. The target audience are Product Owners, Scrum Masters, Developers, and project leaders. The Backlog is about getting the most out of product development.
Subscribe to get new posts straight to your inbox. 

Product development fundamentals

What are we even talking about when we discuss product development? In the end all product teams want the same thing. They want to “build products that our customers love that also work for our business.” (From the great book Inspired by Marty Cagan). 

I love this sentence because it includes a lot. It explicitly states that we need to deliver a product. Implicitly it includes fostering a deep understanding of our users and customers. How else are you going to build a product that your customers love?

The last part of the sentence – “work for our business” – is so important but often overlooked. We need to create our product within the boundaries of a company. This company has a strategic direction that the product must fit with. The company likely also wants to earn money. Finally, there are different departments that have different needs and wishes. The product must work for them as well. All of this goes to say that a significant part of product development is stakeholder management.

That is why I love this one sentence so much. It summarizes the three main, high level activities in product development: determining what to build, building the defined solutions, and stakeholder management. 

Product development consists of product discovery and delivery

Leaving stakeholder management aside for now – I covered it already –  product development is made up of two phases: product discovery and product delivery. 

Discovery is the activity of determining what to build. Product delivery is actually building the determined solutions. The former determines the effectiveness of development (building the right things) whereas the latter determines the efficiency (building things right). 

Both are important. But many companies (and agile coaches) only focus on delivery. I believe this is mainly caused by company culture. In many companies it’s the norm that stakeholders prescribe features. The development teams simply implement these. All the team really can do in this case is optimize delivery since “discovery” is done by someone else.   

Optimizing delivery is important. Becoming more efficient at delivering solutions is great. But the best efficiency doesn’t help you if you are building the wrong things. 

That’s why the leverage in product discovery is incredibly high. One correct decision can have a huge impact. Building the right thing inefficiently is not great. It’s still preferable to being super efficient but constantly building things that don’t move the needle. In that case your product might soon no longer exist. (The role of the Product Owner is so important for the exact same reason). 

Discovery and delivery activities should be done by the same team

In this context it’s important to highlight that discovery and delivery should be done by the same team. Empowering a team means giving it a clear outcome and then getting out of the way. Only then, do you get the best solutions, true ownership of the product, and much more motivated team members. 

In a perfect world delivery and discovery are constantly happening in parallel. Ideally, the team is able to conduct discovery and delivery within each iteration. Focusing on the smallest possible user problem, the team should continuously experiment to remove uncertainty and risk before implementing a solution. 

I realize that this is not the reality for many teams. An alternate route that has worked well for us in the past is switching between phases of heightened discovery and delivery work.

For example, a team could spend a month running bigger tests and experiments to determine what to build. Then, they could spend two months implementing the solutions. During this phase of delivery you have to make sure to build in small increments and constantly monitor if the improvements have the expected impact.

Three things to aim for when working with a team

With the above basics in product development in mind, whenever I support a team, I try to aim for three things. Doing so means we are on a good path to be successful:

  • Getting as close to users as possible
  • Delivering in the smallest increments
  • Minimizing team frustration

Getting as close to users as possible

There is nothing more insightful than seeing a user interact with your product. So many ideas come out of that. Baked into the design decisions are unconscious assumptions about our users’ behavior. Watching them, the team will find that the assumptions aren’t always correct. It’s also incredibly motivating for the team to see the product helping a user.

I really like Teresa Torres’ continuous discovery framework. Without worrying about all of its details, an easy thing to implement is having weekly – or monthly in the beginning – touchpoints with users. The goal is to interview them and gain a better understanding of their  problems and how they use your product. Later on, you can use these regular touchpoints to run small experiments. Simply talking to users is enough in the beginning, though. 

Make sure, there is always at least one developer present for these interviews. They are often forgotten but usually have the best ideas. 

You may not be able to talk to end users directly for various reasons. Nevertheless, try to get as close to them as possible. Minimize the degrees of separation as much as you can. It’s better than nothing to at least speak to your sales people, or your customers, if you are unable to speak to the end users. 

Deploying changes as often as possible

Frequent deployment of changes to the product automatically solves many common issues in product development. Thus, try to improve the product as often as possible and you will avoid problems many other teams have. You get quick feedback loops and will catch errors more quickly, be able to get feedback from users sooner, and become better at deploying.   

The important thing is to monitor the effect of the changes. You can gather feedback by explicitly asking for it (e.g. in a product review), by watching users interact with the new developments, or by monitoring specific product metrics. 

If you are frequently deploying small releases, it’s only a minor step to start conducting experiments. Testing often and early reduces the four types of product risk: viability, feasibility, usability, and value risk of your product.

Minimizing team frustration

A company is not only revenue, roadmaps, and goals. A company is first and foremost made up of people. We cannot forget that. A happy team is a productive team. It’s that simple. 

Also, in the corporate context many are frustrated by bureaucratic, seemingly senseless processes. Try to minimize team frustration. 

Generally, People don’t care about labels, they simply want to have a smooth work process to provide something meaningful. Adapt processes wherever possible. Make sure the tools the team has available are sufficient. Try different things to help them out, see how it works, and adapt if needed. 

When in doubt, bias towards making the team members happy. This will increase your chances of success. And it also helps in convincing skeptical team members to give new approaches a chance.

Forget about labels in product development

The goal for all product teams is to create successful products. I encourage you to place less focus on the labels, frameworks, or methods used in doing so. Focus on the basics of product development: product discovery, product delivery, and stakeholder management.  

Try to get as close to your users as possible by regularly interacting with them. Try to deploy changes to your product as often as possible. Try to make the team members happy. If you do that you are surely on the right track to “build products that our customers love that also work for our business.”