Consider context to pick the appropriate practices for you.

There are no best practices, but there are appropriate practices for your situation.

The term “best practice” is frequently used to describe a process, technique, or practice that was successful for one team, organization or industry and are copied by others who believe if it worked for them, it will work for us.

Unfortunately, a practice that works great in one context may not work as well in a different context or may be entirely inappropriate.

There are no best practices, only appropriate practices for your situation.

You can avoid the lure of best practices when you understand the conditions under which a practice is effective and determine if your situation has similar characteristics.

In other words, understand your context to understand the appropriate practices.

Type of product drives the practices you use

As a product person you need to understand the context in which you’re operating.

Let’s say you’re working on a product that you’re going to sell. If so, do you know what problem you’re solving and for whom you’re solving it for?

Are you selling to individual consumers? Then you’re probably working in a B2C context.

Are you selling to organizations? You’re probably working in a B2B context. And if your customers tend to be fairly large, you may even say you’re working in an enterprise context.

Do the people who buy your product also use it, or are they different groups of people? Depending on you your answer to that, you’re going to use different techniques to understand your customers and users.

What about if you’re working on an internal product, something you won’t sell and will be used inside your organization. You need to have a general understanding of how this product will help your organization serve its customers, but you’ll also need to understand your organization’s processes, rules, and data. Business analysis techniques are helpful here.

You may find yourself working on your organization’s website or mobile app (also internal apps as I use that term). It’s something your customers are going to use to buy your product and it’s also something that helps out people inside your organization with their activities. You’ll need to understand your customers and your organization’s processes in this case.

The structure of your organization drives the practices you use

Regardless of what type of product you’re working on, you’re going to have to figure out how to work with the team building that product. Product ownership techniques come in handy for these interactions.

The trick is, there’s more than one way to organize the product function. There are at least four different ways to organize your product people, primarily based on where the responsibilities for product ownership lie. There are of course multiple factors that determine what model you use.

Your background and experience influence the practices you use

Your past experiences and training influence how you approach an unfamiliar situation. If you come from a development background you’re going to interpret a situation and the proper course of action differently than if you come from a business analysis or project management background.

If you primarily work in startups, your view of roles and organization structure and process are going to be different than if you’ve worked in Fortune 500 companies your entire life.

You can certainly learn new techniques and become proficient in new skills, but you will always tend to see things from a perspective that’s influenced by where you’ve been before. That could be previous roles, it could be previous industries. It’s wherever you did the specific, detailed work that allowed you to build up a specialty.

This isn’t a bad thing. As long as you are an expert in certain practices and understand when they are applicable, this can become a competitive advantage when you move to a new context.

When you understand why a practice works when it does, and are able to pick up new contexts, you can often apply creative ways to solve problems in that new domain. You just need to be aware of your tendencies and be open to learning new techniques or applying existing techniques in new ways.

InsideProduct helps you navigate your context

There are a lot of materials available about product management, about business analysis, and about product ownership separately.

There are not a lot of resources about how to apply those techniques in specific contexts.

There are not a lot of resources that explain how to meld product management, product ownership, and business analysis together effectively.

Until now.

If you’re a product owner, business analyst, or product manager working with development teams to deliver internal products, InsideProduct is for you.

Here are some resources that explore how you can use context to get a handle on working on a product and with a product team.

If you have an interesting experience using context to guide your choice of approaches, please share. I’d love to hear about it.

How to Lead a Product Team With Context

To create an empowered team, leaders should give up control, and they should create an environment where their team members can decide what needs to be done and how. The most important tool leaders can use to empower their team members is context.

Context is all the information people need to make the right decisions on what to work on and how.

In the empowering leadership style, instead of owning all the information, leaders share the information they have with their teams. In this setup, the leader's job is not to make decisions but to make sure the team has the right context, so they can make decisions on the go, without turning to the leader all the time.

Even in empowered teams leaders might be the people who receive most of the information because of their position. The main difference is that empowering leaders actively share information to create context and empower people to make their own decisions.

Empowering leaders also try to build an environment where people continuously receive the most important insights directly, so the leaders don't have to play the middleman.

Dávid Pásztor shares how he creates context in his product teams and the most important information you have to share as a product manager with your team.

Product management in different contexts, explained through analogies

After years spent as a product manager, Austin Yang still doesn’t have a good answer to this question. He’s accepted that there will never be a “catch-all” definition of the role. A product manager’s job varies greatly across different contexts, and each context requires a unique set of mental models, skills, and strategies to be successful.

To illustrate the fluid nature of product management, Austin shows how the role of a product manager differs across business models, company stages, and seniority levels through analogies.

As a quick note, these analogies aren’t perfect, so don’t get too caught up in the technicalities. They are here to put the different flavors of product management into perspective, so you can approach the role with more clarity.

The power of context in product management

Everyone in the world of modern product management is talking about empowered product teams. Every reasonable company wants them, every product leader wants to build them, everyone wants to work on them. But how does a product team become truly empowered?

One of the key jobs of product teams is to decide. Decide what to build next, decide how to build it, decide what not to build. Decide what bad looks like, decide what a solved problem looks like. Product teams make decisions every day. But how do they know they made a great decision? How does everyone else know? And mainly, what does it take to make a great decision?

Jirka Helmich shares his thoughts on how to use context when working with your product team.

Thanks for reading

Thanks again for reading InsideProduct.

If you have any comments or questions about the newsletter, or there’s anything you’d like me to cover, let me know.

Talk to you next time,

Kent