Love Your Constraints

When I first started out in product management, I often saw constraints as frustrating limitations and I assumed that my team felt the same. They felt like obstacles standing in the way of what our team could achieve. But with time and experience, I realized that teams struggled with makind high level decisions without the right constraints in place — usually because there’s no single right answer.

Over time, I found that being decisive and clear in as many areas as possible improves the product you ship, the experience of building it, and your ability to build it effectively. Let’s dig in.

Constraints as a Limitation- The Misconception

It's easy to see why constraints can feel stifling, especially for more junior teams. When you're passionate about a product or feature, anything that seems to box in your vision can feel like an enemy. But here's the thing: those boundaries actually free up your team to focus on what really matters. They reduce the number of decisions that need to be made, provide clarity on what's possible, and, ultimately, give your team the room to innovate within a well-defined space.

Kevin Yien, a seasoned product leader, touched on this elegantly in his episode of Lenny's Podcast.

This insight highlights the strategic advantage of constraints: they provide focus. And in a world of infinite choices, focus is a superpower.

How Constraints Fuel Creativity

So how exactly do constraints unlock creativity? The answer lies in how they force us to think differently. When you can’t go down the path of least resistance, you’re pushed to find new routes. Consider some of the most innovative products out there—many were born from strict constraints. The classic example is how Twitter, with its original 140-character limit, forced users to be concise and creative with their communication. That limitation didn't hinder Twitter; it made it distinct.

My first job out of college was actually in social media marketing and I had to write 5-7 tweets a day for each of my clients. At any point in time I was managing 8-12 accounts, so that ends up being something like 50-75 tweets a day (not counting my own). While I was also writing blog posts and posts for other platforms, I cite that experience and the high amount of reps as the number 1 contributor to my ability to craft effective messaging and copy for almost any product or service across any industry — which seems to have carried over to writing documentation and even prompting.

.

In software development, constraints eliminate noise for the team, allowing them to think more deeply about fewer things. When the team knows exatly who they are building for, they make better assumptions and feel empowered to make stronger recommendations. When the team has clear priorities, they align faster around major design decisions. When the team knows they have specific accessibility requirements, they plan the work ahead of time and also make choices early on that set them up for success. They start cutting out the fluff, honing in on what delivers the most value.

While many of you might not know who 10up is, they have helped build some of the biggest websites and web apps on the planet. Some you probably frequent every day. I worked there for about 6 years and our engineers leveraged our best practices to improve their ability to plan and estimate projects, set clear expectations for every PR, and to generally shape their approach to building whatever thing we were working on.

Defining the Right Constraints

While some constraints like timeline and budget/team size are usually given to you, there are many others that you can identify, shape, or even create to set your team up for success.

1. Start with Purpose

Begin by understanding the project’s core objectives. What are the non-negotiables? Whatever it is, make sure these are crystal clear to everyone on the team. If you’re working on a product with multiple user segments, for instance, a great way to start is by defining which user needs take priority and which can be deferred. This sets the stage for every other decision. This list should look something like:

• Timeline/Appetite - How much time are we going to invest in this?

• Business objectives and 

  - What impact are we expected to create by shipping this?

• Customer segments (prioritized) - Who are we building this for?

• Restrictions and requirements - What regulations or hard requirements have to be met?

  • Do we have to integrate with specific platforms?

  • Do we need to meet specific regulatory requirements?

  • Are we covering all devices?

2. Eliminate Questions

Constraints shouldn’t be handed down from on high without input. One of the best ways to get alignment and buy in from your team is to “sit down” with them and have them tear apart your PRD or brief. The questions that come to their heads right away are probably questions that you can or should answer before anyone starts designing or building anything.

It’s been my experience that taking the time to eliminate questions upfront pays dividends in efficiency for the entire team later.

3. Prioritize Ruthlessly

I don’t want to over-hype Lenny’s podcast but I’ll introduce the concept of the term “side quests” from his interview with Karri Saarinen.

Things that get cut from scope are historically called “distractions” or “nice to haves” or “feature bloat”. While I appreciate using terminology that everyone understands, it’s sometimes hard to hear those labels attached to great ideas.

Kerri uses the term “side quest” to help prioritize, and I think that’s probably the most appropriate mental model I’ve come across in over a decade of building. If you aren’t familiar with video games, specifically RPGs, side quests are essentially missions that you can take on outside of the main story arch. You could play through the whole game without really touching any of the side quests or you could spend hundreds of hours on side quests and drag out the main story of the game.

Side quests are fun and often help unlock new skills, tools, or powers in your character - making progression through the main story easier and a little more fun. Games tend not to introduce side quests until you make it through the “prologue” of the game where they introduce the characters, the world you are in, and how to play.

The MVP for the thing you are building is essentially your prologue. This is the thing that will determine whether you built something of value and are on the right track. Many gamers can tell whether or not they want to keep playing a game within the first 10-30 minutes of playing, and that’s about 10x the time we get to convince customers that our products are worth using.

I like to look at the in progress PRD or scope doc as if someone else wrote it and I am being asked to review and provide feedback. As I go through it, I look for areas where the team diverged from the core purpose or value that set this work in motion. Here are some of the things I will automatically cut or suggest cutting:

• A side quest to make the current thing useful to a customer segment that we’re not building for right now.

• A feature update or change to make the current thing more useful in other workflows.

• An enhancement to the current thing that falls outside of the core purpose and value we’re pursuing.

• Anything tied to scaling usage across an entire customer base - especially if you don’t have the number of customers yet.

It’s easy to be tempted by seemingly small tasks that may make what comes next easier, but it’s generally not worth it. The fear of rework tends to be exaggerated and the “easy” side quest usually runs into a “boss fight” you’re not prepare to take on.

4. Leverage Constraints for Decision-Making

When your team hits a crossroads and is faced with a tough decision, revisit your constraints. They should serve as a guidepost, helping to filter out options that don’t align with the project’s boundaries. This not only speeds up decision-making but ensures that choices are aligned with the project’s goals.

You can use a clear set of questions to cut through the noise pretty quickly:

• Does one of the options we’re considering serve users outside of our core segment?

• Does one of the options impact metrics or objectives that aren’t within our bullseye?

• Are we considering one of these options for a future state of this feature/product that we aren’t sure will exist?

• Does one of the options we’re considering require expertise or resources outside of our core team?

• Are we talking about a side quest?

5. Review and Adjust

Constraints aren't always set in stone. As the project progresses, it’s essential to periodically review them. Are they still relevant? Do they need to be adjusted based on new information or shifting priorities? Keeping constraints flexible yet focused allows your team to stay agile.

The most important thing at the end of the day is delivering value to customers. You need to discern whether your constraints —especially those that are arbitrary or internal — are helping or preventing your team from doing that.

Maybe you decided not to worry about the native mobile app in v1, but discovered that a large portion of your core segment have critical workflows across desktop/web and the native app. It would be silly to ignore the needs of that group of customers just because you already set a constraint. So instead, communicate the insight and update your plans — including the constraint.

From Constraints to Clarity

Ultimately, constraints aren't something to be feared; they're a tool to be wielded. By setting clear, thoughtful boundaries at the start of a project, you give your team the freedom to innovate within a well-defined space. This leads to more focused, creative, and efficient work—qualities that are essential in today’s fast-paced tech environment.

While it sometimes seems like it would be easier or better to eliminate constraints and just build, it’s actually multitudes more difficult to get to a point where you can decide what to build without clear constraints in place.

To put it simply: if you want your team to think outside the box, first give them a box to work with.