Managing 11 common product constraints
It's a rare thing to work in a team and organisation where you have all of the things in place for your team and your product to achieve their full potential. What’s much more common is to be faced with one or more constraints that you either need to learn to work under, work around, or remove entirely.
This article lists out the 11 most common constraints I’ve observed, and a few pointers for how best to deal with them.
The constraints
- Feature fixation
- Financial
- Organisational
- Pressure / scrutiny
- Regulatory / legal / ethical
- Sales-led
- Strategy
- Team maturity
- Tech debt
- Usage data
- User-centricity
Feature fixation
I’ve never worked on a product without there being one or more people that actively push features on you. This is part and parcel of working in product, and you can still create and grow great products whilst managing this noise. But some teams and organisations have it a lot worse than this, to the point that it’s systemic—toxic almost. It’s the default behaviour. It comes from all directions and is overwhelming, leaving no real room for manoeuvre.
Having strategic pillars to constantly refer to will definitely help, but the feature fixation and strategy constraints often go hand in hand unsurprisingly. Aimlessly shipping feature after feature would never align with any credible strategy.
A conversation with leadership—particularly product leadership if there is any— is a good place to start. This is a very difficult conversation to have, and has the potential to be career limiting. It can help to have accrued some credit first by showing that you can deliver, and this will likely give you a reference point for conversations if you have examples of items delivered that had no tangible positive impact.
Assuming that the conversation with leadership hasn’t had the desired effect—and a lot of the time it won’t—the good news is that there are many incremental measures that can move you in the right direction, such as:
- Asking these two questions a lot:
- Do we need this now?
- Is this the most important thing that we could be doing now / next?
- Prioritising strategically and systematically. Even if this is ultimately overruled, just visualising how and why items are on roadmaps and backlogs can affect mindset.
- Measuring. It doesn’t have to be massively scientific, but having some view of how features are being used—if at all—can give you more ammunition. It can make others question their own assumptions, and can prevent you doubling down on features that deliver little or no value.
Financial
This usually manifests as insufficient people or tooling. You can’t have a user researcher. You can’t have any more licences for this SaaS tool. There will always be a limit, but if you genuinely believe that your team is being held back on account of the people or tooling that you have (or don’t have), then I would implore you to raise this with those that hold the purse strings. Not repeatedly, every other day, to the point where it becomes counterproductive, but at least once.
I find it's more effective to be creative though, at a team level. Is there anyone in the team who has an interest in user research, and wants to lead the charge on that front? Is there anyone else’s user research we can piggyback on? Could we save a few quid by cancelling a subscription to that tool we never use so that we can get a few more licences on this tool? Could we be leaner?
Organisational
As companies grow and more and more teams are formed, there tends to be a clamour for consistency. Whether that’s shared ways of working, alignment on tools, or more time spent generally on aligning. There are also increased dependencies that come with scaling. And acquisitions and mergers can bring this to the fore.
These are unavoidable to some extent, but they can be mitigated. In terms of how teams work, then you can definitely challenge the status quo. Again, there’s a grace and subtlety to how you do this, but if your team wants to do something in a specific way that works for you, or wants to continue using a certain tool, make the case to those who say otherwise. The worst they can do is say no.
Mitigating dependencies can be done by logical organisational design (read Team Topologies if you haven’t done), but on a more practical, day-to-day level, can be done by using Team APIs or similar to make it clear how teams work together. Regular comms between teams who are likely to overlap can also help, as can support from those one level up from teams, so those at “head of” or “principal” level.
Pressure / scrutiny
There is a difficult balance to strike. The best teams I worked in have put sufficient pressure on themselves, without needing others to press. Some teams—probably most of them—have benefited from some external pressure, although I do wonder if they were conditioned to be that way. I’ve definitely worked in some teams, though, that have been damaged by too much pressure and scrutiny from those outside the team. Often people in leadership roles, sometimes people in project management, and sometimes people who are closer to customers in B2B roles such as sales or account managers.
As a leader of your team, you can address this in two ways.
First, try to keep some of the noise away from the team. Ensure your noisy colleagues know where to direct any inquiries to, in a way that doesn’t take away from the team’s focus. Just being more proactive with your comms can also help to nip some of these escalations in the bud.
Second, push back. Highlight the damage that can be done by the pressure and scrutiny. Ask if it ever has a positive impact. Try and dig into the root cause. What could you or the team do differently to avoid being in this situation again?
Regulatory / legal / ethical
Examples I’ve come across in my career are the regulatory complexities associated with showing finance costs on ecommerce sites, the ethical issues with building digital products for children, and the legal challenges of building a public service that is underpinned by primary legislation.
The key with constraints like these, is to a) get familiar with them, and b) get familiar with those who know them best.
Write up a wiki one-pager or Miro board on each constraint you have like this. Link out to the bulky documents. Get AI to summarise some of the constraints. List out the experts.
Spend some time with the people in the know - your compliance people, your policy experts, your ethics advisors. These relationships will be key when it comes to the crunch.
One word of caution here though: don’t feel like you always need to take these constraints as gospel. A lot of the time when products butt up against constraints, it’s far from a binary affair. The waters can be muddy. I’ve often seen teams and sometimes whole products mired in bureaucracy that, when you really started to pull at the threads, fell apart under the lightest of challenges.
Sales-led
This is a subset of feature fixation, but can be even more difficult to address. Every organisation that sells—particularly B2B—is sales-led to a greater or lesser degree. This is natural and healthy, but it’s a fine balance.
Where this all too often falls down, is where organisations over-commit to existing and prospective clients. Much like feature-fixation, I’ve seen this at every B2B org I’ve worked at, but it doesn’t take much for this to tie you in knots, and it soon begins to damage relationships and morale.
There are two critical areas where this can be resolved, and both boil down to collaboration and compromise—ensuring that those in product and sales work together.
First, and at the very least, if you feel like the team is unable to move the product forward because of the amount of commitments made and the subsequent follow-up pressure, raise this with leadership. Ultimately, the only way this can be fully addressed is to ensure that product and sales (and realistically the entire org) are aligned on this, and crucially get the balance right.
Second, it isn’t all on leadership. You need to work together with your colleagues in sales and marketing. Ensure they understand what the capabilities of the product actually are. That is your responsibility as much as it is theirs. Ensure that they understand what it is that the team is doing. And why they are doing it. Spend time with them. Go on sales ride-alongs. Review marketing collateral.
The suggestions for feature fixation may also work here. If you can show the trade-offs and the impact of always jumping to build the next thing that’s been promised, people begin to think twice.
Strategy
Without a solid, clear strategy, it can be difficult to build great products. Prioritisation is difficult, cross-team alignment is often lacking, teams can struggle to measure the impact of any changes they make, and motivation and morale can suffer.
The first thing to do in this situation is to determine why this hole exists. Is the expectation on you to fill the gap? Is this on your head of product, or the senior leadership team? Is it a work in progress? What role do you play in defining it, if any?
If you find that you’re going to be without direction for some time, or worse still, there is no clarity at all on the horizon, then I’ve found that the best thing to do is to set the direction yourself. Work with your team to create a handful of artefacts that will force you to ask and answer the questions that have previously gone unanswered. Artefacts such as:
Team maturity
Perhaps maturity isn’t the word here. This is effectively you as the product manager not being able to spend enough time on your highest value activity—discovery—because your attention is firmly on delivery. It’s usually one of four things:
- Your team does not have the skills or the confidence to lead delivery
- You do not trust your team to lead delivery
- You feel more comfortable in delivery than in discovery
- Your leaders expect you to focus on delivery
I’ve encountered all of these. I’ve been in teams where multiple have applied.
There is no harm in showing by doing when you join a new team that isn’t as experienced as you are—something I strongly recommend in my Starting a new role article (8 minute read). But you do risk making a rod for everyone’s back if you continue to lead the charge. Your team can almost certainly own more of delivery than you think. Give them a try. Consciously ask them to help out further upstream. To participate in discovery. To break down and shape backlog items (if that’s how y’all work). It’s very unlikely you’ll be able to do sufficient discovery if you’re constantly pulled into the weeds of delivery.
This takes awareness and discipline. I still regularly end up doing too much delivery, and whilst it feels like the right thing to do, it’s just short-termism. Before long you’ll realise that your strategy doesn’t hold up, or your discovery will be full of holes.
I’d also advocate making time for personal development, as a team. Often each discipline is encouraged to dedicate some time to their personal development, but this can often fall down when the demands of the team take over. Make sure to champion this and set an example. Block out development time if you have to.
Engaging a delivery manager, or some focused team development on delivery management can also help. As can a roles and responsibilities session, and a grounding in the fundamentals of discovery, delivery, and the core elements of each of the different team roles.
Tech debt
You can read more about my views on tech debt (15 min read), but suffice to say that the scale of it, and how you as a team manage it, will likely have a big impact on your medium-to-long term trajectory.
For the purposes of this article, I will also include all of the production-grade elements of engineering that you require to operate at scale, such as CI/CD, automated testing, and comprehensive observability.
For those starting with a clean slate, I would advise one of two things.
First, either accept that your stack is throwaway from the start, or go the other way and bake in the non-negotiables as early as you possibly can.
Second, acknowledge your tech debt. Write it down. Represent it on any backlog or roadmap artefacts you have. Discuss it regularly. Strive to keep on top of it.
If you inherit a product that is in a bad way, then get in front of it. Again, write down what is missing. Get sight of impending tech work early. Ask the question if it’s worth starting again—I’ve worked in several places now where I genuinely believe the product would have been in a much healthier state in three to six months if had been scrapped and rebuilt from scratch.
Regardless of what state the stack is in, the main thing is collaboration. Open dialogue with your tech lead. Leadership alignment across the functions. Product and engineering are two sides of the same coin.
Usage data
Prioritising and measuring impact without usage data is little more than guesswork. Going off an opinion doesn’t cut it if you’re serious about building impactful, market defining products.
As ever, the ideal is to bake usage data in from the start. It sounds simple, but it should be one of the non-negotiables of a new product build. If you do things right, then you’ll already have defined health and success metrics before you begin to build, so the key here is to a) call this out as a discrete deliverable as part of your early-stage development, and b) ensure that you always factor in to any new developments going forward.
It doesn’t have to be all-singing and all-dancing though - it can be manually collated to a degree if needs be. The key is that anyone in your team can answer a question about your health and success metrics, and the team can answer it easily without any further development. If you manage to go one further and you’re able to answer open, exploratory questions about your product, then you’re way ahead of most teams.
To that point, I’d say at least two thirds of the teams I have joined have not had the necessary infrastructure and skills to utilise data effectively. When this is the case, there are a few things you can do to address this, and also look to other sources to alleviate blind spots.
First, prioritise usage data. What’s the minimum that you can do to get some usage data out of your product. It could be embedding an analytics tool. It could be getting your operational data into a data stack and dropping a BI tool on top of it. It could be manually going into your product and pulling out some data periodically. You can and should try to do this, and it doesn’t mean that you need to stop working on other more classical work items whilst you do it.
Second, if you are struggling for data points, there are other sources you might be able to go to in order to better understand how your product is used, such as:
- NPS surveys or similar
- Social media
- Trustpilot, Google reviews, app store reviews or similar
- User research
- Complaints, service desk tickets or similar
User-centricity
As organisations grow, it tends to become more and more difficult for teams to interact with users, and the overall focus on users can decay as a result. This can be even more challenging in B2B organisations, particularly with complex business models, where the team is further removed from users, and there may be strategic reasons for keeping teams away from users.
Working in a product team, it is critical for you to strive to understand your users. Not only do they determine whether your product succeeds or fails (and therefore whether you continue to have a job), but they are also your best resource. Your best source of learning.
It takes discipline and resilience, but this really is a fight worth fighting if you want to ensure that your team focuses on what matters, and also to ensure that you foster a team of missionaries rather than mercenaries. If a team cannot see users using the product that they spend so much of their time building, then empathy, morale, and motivation will always be lacking.
If you aren’t lucky enough to work in an organisation that has a healthy cadence of user contact, then you can still do something about it. In B2C, then there’s nothing stopping you arranging our own sessions, other than perhaps budget and time. If your product has a wide target market, then that can make it easier to use guerilla tactics to help build up a picture of your users. In B2B, speak to your sales teams. To your account managers. You may be surprised at how simple it actually is to drop in on a sales call, or to make a cameo on a fortnightly account review call to ask a few questions or get feedback on a prototype.
A lot of the usage data guidance applies here also. Usage data and user research go hand-in-hand, and you can often make do with one where the other is lacking.
In summary
Practically every practitioner, team, organisation, and product is under constraints. Some can be bent. Some can be broken. Others persist. The real skill comes in identifying and managing them, whilst all the time pushing your product forwards. It takes adaptability, guile, and persistence, but it’s a challenge you’ll need to take on if you want to build a truly great product.
