Your unique constraints

Leveraging your company or product’s unique constraints to adapt your team’s product practices

Product management is a career that many individuals arrive at by accident. Over the years, I’ve met so many of you and heard your stories about how you found this role: someone saw potential in you when you were an engineer, and ask if you’d try it out. You were doing QA on your team and were given a small product assignment that led to a full time role. You have a passion for building things, and someone suggested you apply to a PM role at a startup. It often goes something like that.

Because of this, it is critical for us to learn from each other — most of us didn’t study this in a book or in a classroom. We learn on the job, and we learn from each other’s experiences. We build our skill set at companies with specific ways of working, with teams that help us shape what good and bad product management can look like.

When you take on a new product role, it can be easy to assume you’ve seen it all before — you can apply this workshop or framework to a problem, and get the same outcome you did as last time. When you’re speaking to a friend in product at another company, you might think how easy their problem sounds and recommend doing something you’ve tried before.

But this neglects one extremely critical aspect to product management: your product or company’s unique constraints.

What are unique constraints?

A unique constraint is a challenge or limitation that exists right now, specifically for your company, market, product or team. While these challenges might exist for your competitors, there is likely a combination that is specific to your situation.

When you hear the word constraint, you might have a negative connotation. But in the world of creating products, constraints can also be great! If anything in the world is possible, a constraint can be used to help you hone in on the area you could or should be working in. It can help give you focus and clarity.

Depending on what your company is focused on, or what problem space your team aims to solve for, you have unique constraints!

A Tale of Two Teams

Let’s consider team 1: your team works in a medium size insurance company, and you focus on building products for internal users. You are a small group of developers, product managers, and designers inside a larger, more traditional insurance company, where the tech team really only makes up a fraction of the company’s employees. You might list your constraints:

• Historically high reliance on legacy systems that haven’t changed much in years
• Small team that is responsible for the entire stack
• < 200 users of their products

By explicitly calling out these constraints, this can help you more clearly identify: what about these things makes your job as a product manager easier? What makes it harder?

In this example, given that you build for internal customers, while your scale might be limited or your users appetite for innovation may be lower, you might be able to much more easily contact those users or do casual user interviews. On this team, a usability test might be the easiest thing in the world to conduct since you don’t need to worry about scheduling or compensation — you can just pop over to someone’s desk. Given the size of your user base, it might be challenging to see patterns in the data like you would with scale, but on the flip side, your team may be able to spend less time prioritizing features for scale and instead deliver other types of value to your users.

Let’s consider team 2: your team works on a direct to consumer product with millions of users everyday. Your team sits within an R&D group in a tech-focused company where technologists make up a majority of the company. While you have a product line that goes direct to consumers, you also have a group who focuses on the enterprise product with a vast sales team to sell it. Your constraints:

• Given your product goes to consumers and enterprises, you have to be careful about what you introduce to consumers for free
• With millions of users, you need a high level of confidence in small changes or the company could lose revenue and reputation
• Your team is one among many that is required to get a new feature out: you must coordinate heavily with others to release

In this example, your team might need to do more testing to ensure your release confidence is high; however, when you release a new feature, your team will get feedback 10x faster on that feature given the scale. It might make sense for this team to run more small experiments and do A/B testing, rather than do frequent in-person interviews for their feedback loops. Given that your team needs to coordinate with many other teams, you might adapt creative ways to share knowledge between teams while optimizing for speed to delivering value.

Why is this important?

I believe there are a few reasons that considering these constraints are important:

1. Understanding your unique constraints can help you adapt your team’s product practices. On that first team, your user feedback might come explicitly from talking to colleagues. On the second team, you might do more A/B tests or surveys to achieve similar results. Both are great ways of getting feedback, but the constraints help you choose the right practice or activity.
2. It can help you and your team put your work and accomplishments into perspective. It can feel really easy to compare yourself to a colleague PM — you might see them releasing new features everyday and assume that your team should also be doing that. Your team may have more security or legal constraints, perhaps you instead release once a week — and you may have worked to bring that down from once a month! This may very well be a huge win for you and your team.
3. By making these constraints explicit, you can challenge them. Are these really the way things have to be? Consider a world where you’re building for a less technically savvy segment of users: you believe there’s a constraint where they won’t adopt new features at the same cadence as those who love new tech. But what if the world has changed since you originally formed that opinion? What if those users would actually welcome your improvements more regularly? By articulating this constraint, you can question it over time.

When you meet new product peers, when you hire, when you share knowledge across product teams inside your company: start by explaining the constraints that exist for you and your business. This will help others better understand the approach you take to building great products. When you start a new role, seek to understand these constraints for your new team. This will help you adapt your practices to be appropriate for the new role. Embrace your constraints!

Thanks to Tim Lombardo for the inspiration for this post.