Finding product-market fit (PMF) is supposed to be the hard part.

You fight for years to find the right problem, the right segment, the right wedge into the market. You say “yes” to almost anything that moves the needle. You ship fast, you bend the roadmap for key customers, you push the team hard.

Then you get there. You have a clear customer profile. Revenue is growing. Renewals look healthy. On the surface, things seem to be working.

Internally, it feels very different. Everything is moving slower.

Roadmaps keep changing. Sales bring an “urgent” request every week. Engineering is permanently at 110% capacity and one incident away from burnout. Leadership meetings drift into status reporting and firefighting. Nobody is quite sure who decides what anymore.

This is the post-PMF hangover. It looks like a people problem. In reality, it’s an operating system problem.

What “post-PMF” really changes

Before PMF, the company is essentially in exploration mode. The main questions are:

• Is there a real problem here?

• Will anyone pay us to solve it?

The operating model optimizes for speed and learning. Founder heroics and opportunism are features, not bugs.

After PMF, the context changes.

Customers start to treat you as a serious part of their workflow. They expect stability, predictability, and some level of roadmap visibility. Sales has repeatable patterns. Investors raise their expectations. The cost of being sloppy goes up.

The problem is that most teams try to run a post-PMF business with a pre-PMF operating model. The same behaviors that helped you survive early - saying yes to almost everything, reshuffling priorities for each big logo, absorbing complexity “for now” - become the exact things that stall you later.

Post-PMF is the point where you need to accept that you are no longer a scrappy experiment. You are an operating company. And operating companies need a conscious operating system.

The old model: heroics as process

If you map how decisions are made in many post-PMF companies, you’ll see a pattern.

Priorities are set implicitly, through a mix of founder preferences, the loudest internal voices, and whichever customer escalation is currently on fire. The backlog becomes an unstructured list of everything anyone has ever asked for. People learn what “really matters” through hallway conversations and last-minute pings, not through any shared plan.

In that environment, progress depends on a handful of heroes: the senior engineer who “knows the system”, the product leader who holds everything in their head, the account manager who can always get things unstuck.

This works surprisingly well for a while. Then the company grows. More people and teams are added. The product surface expands. Enterprise customers appear. The complexity compounds, but the underlying way of working stays the same.

You see the symptoms:

• context constantly lost in handovers

• teams tripping over each other

• initiatives started and never properly finished

• people burning out because the only way to make anything happen is to push through the chaos

The conclusion is simple: you can keep the hero culture, or you can build a scalable business, but not both.

What an operating system actually is

When people hear “operating system”, they often imagine heavyweight process: frameworks, tools, ceremonies, new layers of management.

That’s not what you need.

At its core, an operating system is a small set of explicit answers to a few questions:

• How do we decide what matters?

• How do we allocate our limited capacity?

• How do we handle new information and new requests without derailing everything?

• How do teams plan, ship, and learn?

• How do we know if we are winning?

Most probably there are already answers to these questions today. They are just implicit and inconsistent. They live in people’s heads, in the habits of the founding team, and in the power dynamics of the leadership group.

Making the operating system explicit doesn’t mean adding bureaucracy. It means replacing ad-hoc, personality-driven decision-making with something that survives growth.

From idea soup to deliberate bets

Post-PMF companies rarely suffer from a lack of ideas. The problem is the opposite: everything looks important.

You want to enter new segments. You want to deepen the product for your current customers. You want to “do something with AI”. You want to clean up technical debt. You want to improve UX. You want to build that one feature that will “unlock” a big account.

If you treat all of this as one big backlog, you guarantee that nothing will really finish.

The first shift is to move from a backlog mindset to a portfolio mindset.

That means defining a small set of explicit bets, each with a clear problem, a target customer, an expected impact, and a rough time frame. Instead of twenty items competing for attention, you have, for example, four initiatives that describe where the company is actually placing its chips.

This has two important effects.

• First, it forces real trade-offs. When a new opportunity comes in, the question becomes: Are we willing to displace one of these current bets to make room for this? If the answer is no, the decision is visible and honest.

• Second, it gives teams visibility to overall strategy. People can finally see how their work connects to something bigger than “tickets”. That tends to improve both motivation and accountability.

You can still keep a backlog. But it becomes a supporting tool for each bet, not the primary way you think about the product.

Aligning structure with how value is created

The next constraint is organizational.

A common anti-pattern is to scale the product and technology organization by simply adding more of what you already have: another PM here, another front-end or back-end team there. On paper, the org chart looks tidy. In reality, the work doesn’t have a natural home.

If you step back and ask where value is actually created, the picture usually looks different. Customers experience your product through journeys: onboarding, core workflows, reporting, integrations into their environment. Internally, there are platform capabilities that power many of those journeys.

An effective post-PMF org leans into that reality. Stable, cross-functional teams own meaningful slices of the platform or the customer experience, end to end. They are accountable for outcomes in their area, not just for delivering tasks.

This requires you to get serious about role clarity as well.

Product decides which problems to solve and why. Engineering decides how to solve them in a sustainable way. GTM brings in market context and customer signal, and owns how solutions are positioned and sold.

When any of those responsibilities are blurred, decisions either stall or get made in the wrong place.

At a certain point, you also need leadership that can hold this system together. Hiring “one strong PM” to “figure out product” in a post-PMF company is wishful thinking. You need someone who can operate at the same altitude as the rest of the exec team, translate company strategy into product bets, and design the environment where teams can do their best work.

Without that, the company will keep defaulting to opportunism.

A boring, predictable rhythm (that frees people up)

With a clearer portfolio and a structure that mirrors how value is created, you still need a rhythm for how work moves.

A simple pattern that works well in many B2B SaaS companies is to make decisions on three cadences: one longer, one medium, one short.

On the longer cadence, typically quarterly, you revisit the big bets. Are they still the right ones? Do you have evidence that they are working? Do you need to reshape or replace any of them? This is where leadership reaffirms the direction and adjusts the portfolio.

On the medium cadence, usually monthly, you review progress against outcomes, not just output. You look at whether initiatives are actually moving the metrics you expected, where teams are blocked, and where you might need to reallocate capacity. This is where you keep the system honest.

On the shorter cadence, teams run their own planning and delivery rituals: weekly planning, stand-ups, retrospectives. The key is that these rituals are anchored in the initiatives they own, not in a never-ending stream of disconnected tasks.

Once this rhythm is in place, something begins to change: people stop living in a constant state of surprise. They start understanding when decisions get made. They start realizing when to bring issues up. They know what is stable and what is up for debate. That alone reduces a lot of friction.

Handling inbound demand without becoming a ticket factory

One of the hardest parts of post-PMF life is the constant stream of inbound requests.

Sales needs a feature to close a deal. Customer Success wants a tweak to retain a key account. Big customers send detailed wishlists. Leadership sees something in a competitor’s release and wants to “match it quickly”.

If you try to satisfy all of this directly from the roadmap, you will end up as a ticket factory. Teams will be stuck reacting to whoever shouts the loudest.

Sounds familiar?

You can’t stop the requests, and you shouldn’t. They carry valuable information. What you can do is change how they are handled.

• The first step is to funnel them into a visible intake process. Not a black box, but a simple, consistent way for requests to arrive with basic context: which customer, what problem, what business impact, what urgency.

• The second step is to make it clear when and how these requests will be evaluated. Some will map neatly to existing bets. Some will shape future bets. Some will be handled as configuration or services work. Some will be rejected. The important thing is that the reasoning is explicit.

The conversation with stakeholders also changes. Instead of “we don’t have capacity”, the message becomes: “Here is what we have already committed to this quarter and why. To take this on now, we would need to pause or shrink something else. Is that the trade-off we want to make?”

People may still be unhappy with the answer. But they will understand it. Over time, this drives better behavior upstream as well. Sales will think more carefully about what they promise. Customer Success will learn to separate true blockers from nice-to-haves.

Building a shared view of reality

All of this only works if the company has a shared sense of reality.

In many organizations, metrics are fragmented. Sales talks about bookings. CS talks about NRR (Net Revenue Retention). Product shows adoption charts. Engineering shows deployment frequency. The CEO talks about “momentum”.

If these views don’t connect, decision-making becomes a battle of narratives.

Post-PMF, you don’t need a perfect analytics stack. You need a small set of metrics that everyone can look at and agree on.

A useful starting point is a simple hierarchy.

• At the top, company-level outcomes: revenue, retention, margin.

• Under that, product-level indicators: activation, depth of usage in core workflows, time-to-value.

• Under that, delivery and quality signals: lead time for changes, incident rates, defect trends.

For each major bet or initiative, you then define a small number of specific measures that describe what “working” looks like. Not twenty KPIs, just two or three that actually reflect the change you expect in customer or business behavior.

When everyone looks at the same facts, disagreements become easier to resolve. You may still argue about what to do, but at least you’re arguing from the same baseline.

Keeping complexity in check

There is one more ingredient that often gets ignored: complexity.

As the product and organization grow, complexity accumulates almost automatically. Every exception for a big customer, every quick workaround, every half-finished experiment that nobody has the courage to remove adds a little more entropy.

Individually, none of these decisions look dangerous. Together, they produce products that are hard to change, hard to operate, and hard to reason about.

If you want your operating system to remain effective, you need to treat complexity as a first-class constraint.

That means being explicit about where you permit customization and where you don’t. It means investing in platform capabilities that solve problems in way that is applicable to the majority of your user base, instead of applying one-off patches. It means building a habit of deprecating features and paths that no longer make sense, even if someone somewhere still likes them.

It also means recognizing that complexity is not just in the code. It lives in processes, in pricing, in contracts, in the organizational chart. If you stop simplifying at every opportunity, the system will eventually grind itself to a halt.

A pragmatic 90-day reset

All of this can sound abstract until you ask: what would you actually do in the first three months of trying to fix it?

The outline is straightforward.

In the first month, you focus on understanding the current operating system. You talk to people across functions and levels. You follow a few pieces of work end-to-end to see how they really move. You map where decisions happen, where they stall, and where they get undone. You identify the recurring failure patterns that everyone quietly recognizes.

In the second month, you sketch the new spine of the system: a first version of the portfolio view, a clearer definition of who owns what, a simple planning and review cadence. You test it on a limited scale: one or two teams, one or two initiatives, rather than rolling it out to everyone at once.

In the third month, you start widening the scope. You bring the leadership team into a regular strategy and portfolio conversation. You align the rest of the organization on the few bets that matter. You begin using the new cadences for planning and review. You make a couple of visible trade-offs to signal that this is not just another slide deck.

You won’t fix everything in ninety days. You will still have legacy complexity, interpersonal dynamics, and real-world constraints to deal with. But you will have shifted the company from operating by accident to operating on purpose.

And that is the real transition after product-market fit: not from small to big, or from startup to enterprise, but from improvisation to an explicit operating system that can carry the weight of growth.

In the fast-paced world of technology and innovation, businesses often find themselves on a relentless quest to deliver more and more features in their products.

Imagine a race where the finish line is perpetually moving. In the tech world, that's often how it feels. We compete with time and competitors to deliver more features, thinking that this will ensure our product's success.

And what’s worse, most often this feature-centric approach is deeply ingrained in the development process of companies. However, the truth is that the obsession with shipping features isn't the key to success.

You can think of it like this: You have to provide value to customers (address unmet needs) in order to get value in return (revenue).

So the question essentially becomes: how can we provide more value to customers?

In order to understand how to provide value, you have to shift the focus to the problem space.

Subscribe now

Obsessing with features

If you work in product development this will probably sound familiar: There is always a bottomless backlog of features, every stakeholder has a specific (and urgent!) request for certain functionality and the CEO has a certain pet feature they want to see in the product.

However, in this race to deliver, we frequently lose sight of the true goal - to create products that genuinely meet the needs of our customers.

More features equals more value, right? Unfortunately no.

The challenge with this thinking is that it can lead to the development of products with a plethora of unused or underutilized functionality.

Or, in other words: product bloat.

These features may look impressive on paper, but if they don't address real customer needs, they can they can become mere distractions.

For instance, think about all the apps on your smartphone. How many features do you actually use in each app? Research indicates that between 60% and 80% of features in many products are rarely or never used. This is a costly oversight in terms of resources and a missed opportunity to build features that would actually lead to happier customers.

The Need for a Shift in Focus

Imagine this: instead of rushing to check off a list of features for the next release, to work cross-functionally to understand what the unmet needs of our customers are and deliver specific solutions to address them.

Instead of simply delivering more, we should be aiming to deliver what matters most.

This is the essence of the value-based approach to product development.

Plotting the path to value

Shifting to value-centric product development is not merely a change in mindset but a transformation in your entire product development approach.

Here's how to make it happen: invest resources in understanding customers, frame goals around value created and continuously iterate to improve.

A key component is to invest in product discovery in order to understand your customers deeply. Define your ICP (ideal customer profile) and stick to it. Conduct interviews, surveys and gather feedback about the pain points and unmet needs of your customers. Ensure that you're not just building what seems like a good idea but what solves real underlying problems.

It also is crucial to define clear success metrics for every initiative before you even start development. Put in (electronic) paper how you will measure the success of each proposed feature or initiative. Ask:

• What is the right metric to use that is directly or indirectly connected to user value?

• What is the baseline for the selected metric?

• What is the potential uplift for the selected metric if we build the feature?

• How and when can we actually measure it?

• Does it worth the cost of building it (and the opportunity cost of not building something else)?

Notice that this way, features are not done when they are released (a customer retention metric won’t move the day after the release!), but after we can measure the impact on the selected metrics.

Finally, it really helps to adopt a continuous iteration mindset, instead of going big-bang-everything-perfect. Recognize that the first version of your product won't be perfect. In fact, it shouldn't be. Put the product in front of your customers early, in order to learn, gather feedback, and iterate based on real-world usage. This approach lowers the risk of spending too much resources to bring something to life that does not provide value.

The potential upside

The core argument remains the same: You have to provide value to customers (address unmet needs) in order to get value in return (revenue).

Let’s examine this cause and effect relationship in more detail.

Customers hire a product to cover a specific set of needs (see Clayton Christensen’s Jobs-to-be-done framework). A product that seamlessly aligns with customer needs has the capacity to elevate satisfaction levels. Happy customers are not only more likely to remain loyal but also become vocal advocates for your brand. Customer satisfaction is the bedrock upon which lasting customer relationships are built.

Also, in the world of subscription-based businesses and beyond, customer retention is a vital metric. As you would expect, customers are more inclined to stay with a product that meets their needs, thus reducing churn rates. The result is a more stable and predictable customer base, which is crucial for sustainable growth.

The cumulative impact of improved customer satisfaction and enhanced retention has the capacity to translate into substantial revenue growth. Satisfied and engaged customers are more likely to make repeat purchases, and tend to act as brand advocates, which can drive new customer acquisition.

In the long run, revenue growth is the ultimate testament to the success of a value-centric approach, establishing a strong and sustainable position in the market.

Challenges and How to Overcome Them

Shifting from feature-centric to value-centric product development requires a change in mindset, processes, and sometimes even the company culture.

Securing the resources to be able to consistently explore the problem space requires significant internal selling. Organizational gravity has a tendency to pull discussions into the solution space (“but we just need a button there!”), while you need to be shifting the discussion into the problem space. Be ready to be challenged about the front-loaded cost of discovery work.

Stakeholders with domain expertise and not familiar with the process are the most difficult ones to convince. “Don’t waste time figuring out what to build, I will tell you. You can thank me later.“ (although they don’t usually tell you the second part). The curse of knowledge at work.

As a product leader you will have to present a structured case for these investments and be able to convince management and peers to make it happen. You will need to show how the process works, what are the benefits and point out specific examples you can start with. And when you get support, you have to make sure to show some quick results if you don’t want this trust waivered.

Conclusion

Shifting from a feature-centric to a value-centric approach in product development is not a simple switch; it's a strategic transformation. But it's a transformation that's essential for success in today's customer-centric business landscape.

It's about delivering what truly matters to your customers and reaping the benefits of higher customer satisfaction, retention, and revenue.

Empowered product teams are one of the key pillars of creating successful products at scale. However, creating and nurturing an empowered product organization that can execute effectively is one of the toughest parts of product leadership.

As I have experienced it, there is a fine balance of too little and too much space given and it takes practice and constant attention to get it right. This article is written from the product leader’s perspective and explores the practicalities of empowering teams in a consistent way.

Subscribe now

A framework for empowerment

Empowering a team is essentially demonstrating trust in the team's ability to make decisions, even when you are not present. It is a critical component to scale a product organization, as after a point you cannot be present to all decisions. And even if you insist on being, you will quickly become the bottleneck.

The premise is simple: You set a direction, provide context and boundaries and let the team execute.

In practice though it is not that simple. There are a lot of nuances and just following the above checklist and hoping for the best will usually yield random results. Whereas as a product leader you should aim for consistent results.

In my view, a good framework for empowerment is based on the following key components:

• Constraints

• Context

• Clear direction

• Expectations and accountability

• Team composition and maturity

Elements of empowerment

Constraints

A key component to make empowerment work is proactively communicating any constraints and relevant context to the team. For example, if there are budgetary or regulatory constraints, then the team will need to take them into account or they risk getting to a direction where the leader will need to come in and ‘correct’ things. Whereas in reality this could be avoided by providing the necessary information beforehand.

More experienced teams will proactively ask these questions, but I view it as the leader’s responsibility to make sure that the necessary constraints are there, regardless of who asks for them. If the team is not experienced enough to ask them, it is also a very good opportunity to coach them in doing so in the future.

Context

Another important component is providing appropriate context. Context can be about the market, about the organization or about past experience with a given initiative.

For example, if you, as a leader, are an expert in the market, it will greatly help in getting the team up to speed and not have them reinvent the wheel by themselves. Careful though, I don’t support prescribing the solution that you may already have in your head, but providing the team with all the necessary information and being available as an expert resource when they have more questions.

Context also applies to the organization. Who will they need to talk to in order to get more information? Who will help them speedrun that legal review? Who in business development will the team need to onboard as a partner from the start, so that he won’t feel left out (as he usually does) and bite back later? Some may view these as mild politics, I choose to view them as being more efficient working in an organization of people.

And finally, context applies to past experience. Have we tried this before? And how did it go? What worked well and what didn’t? What’s different this time?

Clear direction

It cannot be overstated how critical is to have a clear overarching direction. This translates to a well articulated vision, a product strategy and a strategy deployment framework that is fit for the organization. How to form and deploy a sound product strategy is subject for another article, but I will briefly touch on it in the context of empowerment.

A common mistake is having a great vision but not a suitably detailed product strategy. This causes a gap in understanding for the product teams because they cannot make a clear connection to the current state of things and the ideal reality of the product vision.

A clear product strategy answers the questions:

• What are the opportunities we can capitalize on?

• Why are they relevant to us? Why now?

• Who are our customers?

• How are we going to be different?

• How are we going to generate business value?

• What is not our focus?

And so on. In many cases the irony is that a high level product strategy is defined in the minds of executives or founders but there is not clear articulation and constant communication about it. You know where you need to go and how we have the best chances of making it happen. Why not make it known to everyone so they can help do so?

Expectations and accountability

On an initiative level, the team also needs to know what is expected from them and that they are accountable to deliver it. So, before teams begin work on an initiative make sure that the following are clear:

• What is the ideal state we need to be when we call this initiative as done?

• What are the relevant metrics to gauge success?

• By when?

• What are the checkpoints for progress?

The more detailed the expectations at the start, the better the chances for good results are. I remain astounded by people who give a two-liner direction to a team, but will create 200 word prompts for ChatGPT.

Also, teams should be held accountable for generating the agreed outcomes. If you give the freedom without holding people accountable for results then it is not empowerment, it is abdication. If you use OKRs, it is a good practice to incorporate these outcomes as key results on the team level.

Team composition and maturity

Something I learned along the way is that building products is actually a people problem. You cannot have the same expectations from a team consisting of junior members compared to a team consisting of senior professionals.

So, as a leader you need to ask:

• Is the team properly resourced to succeed?

• Do they have all the skills they need?

• Do they have leadership skills inside the team, someone who will help them self-organize?

People dynamics matter, despite what your average project manager friend says.

Also, the concept of the “x10 employee” is real. You need to spot them and have them work on your key initiatives. They will help move the team forward considering that they can work with people (beware of brilliant jerks).

Beyond that though, you will need to carefully balance teams so that they are equipped to deliver but also work as an incubator for more junior members to learn and grow along the way.

Tactical considerations

On a tactical level, there are some techniques that help.

One pagers

A concept that works well is having the team craft an one pager for each initiative before they start working on it. You know, actually write down all the relevant details, the why, the connection with strategy, the metrics and any relevant information that can help align the people on why we are burning money and time on something. This way the team will be forced to ask for this information and the leader will be forced to provide them. And writing things down has the added bonus of forcing people to think more clearly.

Time plans

While empowering people to be creative is great, you will need to provide some time constraints, so that people are pushed to work efficiently. Speed matters and especially in startups lack of speed means death. So, for any non trivial initiative ask the team to create a plan with some clear milestones and put dates on them. Although it may sound too strict, it will help the team focus on good execution. Have frequent progress reviews at certain milestones and be open to reworking the plan if it makes sense as you go. E.g. “We are learning a ton during this week’s onsite with customers so it makes sense to spend a few extra days doing so.”

Product reviews and retrospectives

And finally, it immensely helps holding a review when an initiative has reached completion. This may be when it is released, or even better it may be when it has been released to a small subset of customers for some period and there are metrics available to see how well it performs.

The review ceremony is a great occasion to celebrate successes and remind people what the product strategy is. A separate retrospective of what went well and what didn’t also helps teams improve the way they collaborate and evolve their way of working.

Final words

As stated before, there is a fine balance of too little and too much space when trying to empower teams. Too little and you don’t actually empower people; too much and you risk creating chaos. Having clarity on the different elements of empowerment, their impact and the accompanying tactics will definitely help you move towards the right direction. And as with everything, an evolutionary approach is best; starting from somewhere and keeping an open eye to evolve your approach based on what works and what doesn’t.

Share

Ever seen a job ad for a product manager/owner from an early stage company that looks more like a laundry list than a real product role spec?

It may mention the words ‘agile’, ‘backlog management’ and so on. After talking to the hiring manager it is evident that they (or anyone in the company) don’t understand what product management is about. They copy-pasted a job description from the internet and intend to place the new hire under the head of engineering or the head of operations.

Plus there is no outcome based goal setting for the role, no metrics approach and a lip-service focus on the customer (or no focus at all). People who sign up for the job often end up being the backlog manager, plus do whatever else feels product-y and no else wants to do (however not actual customer driven product management).

Subscribe now

Why does this happen?

This is caused when there is no understanding about what product management really is and how it contributes to a company's success. And in turn, the root cause is because there is no product leadership talent internally to drive such understanding.

Experienced product leaders are necessary to build the product function. It cannot be done based on assumptions, 'what seems to make sense' and ideas from blogs or books alone. You would not set up the finance department without having someone in charge with good knowledge of the finance domain, would you? Why do it for product management?

This is a complicated role, with much (much!) nuance and people need to have experienced it if they hope to be good at it. Same as all specialized roles. To become a great product leader people need to have worked alongside more experienced product leaders in their careers, to have seen things done correctly, to have tried and failed and learned from those mistakes before trying again.

What the impact is

Hiring a mid-level product manager without proper product leadership guidance, usually results in them ending up as demotivated project managers with a different title. It is a lose-lose situation for everyone. Consider the following effects from the lack of product leadership:

• The company cannot execute on a clear product vision and falls back on opportunistic methods like the idea circus, the HiPPO planning (the Highest Paid Person's Opinion) and other merry but not-fun acronyms. With no one on the ground to drive a cohesive product vision, teams cannot execute with focus and the product ends up being a messy collection of features.

• Eventually there is high turnover among builders in the company, as people feel like task-pushers without understanding the greater picture of what they build. They will soon accept a slightly more competitive offer in another company, but the real reason for leaving is not the money.

• Executive leadership is not happy: From their perspective, they brought product talent in-house and he/she failed to do their job. Executive leaders lose faith in the existing product people and will often:

  • Place someone they trust and is already in the company in the product leader's position, without necessarily having job specific experience. The reasoning is that "he/she did well on X, so he/she will probably do well here too". Personally, I have never seen this work well, as the skill-set required for product leadership is rather specific and nuanced and smarts alone don't cut it.

  • Try to do the product leader's work themselves. Usually the worst option, given that they have no expertise (that's why they hired a product manager in the first place). Not only that, but they often succumb to confirmation bias of their own views and have the organizational weight to see them through anyway.

  • Eventually bring in a product leader from outside to fix things, but precious time has been lost (the opportunity cost is huge) and it usually does not work well with the existing product people who get layered.

Some context setting

Andy Grove, the former CEO and co-founder of Intel talked about the notion of 'task relevant maturity' in his book 'High Output Management' (a great book, you should read it if you haven't already). He describes it in terms of the level of supervision that an employee should get based on how familiar they are with the task they have been given. In simplified terms, what he proposed is that if the employee is experienced with the task given he should be allowed to execute with minimal supervision, whereas if they aren't, the manager should closely supervise to ensure that the task is correctly executed.

I would like to use the task relevant maturity framework in the current discussion from another angle. Consider that you are a company that wants to hire a product person but does not really understand what product management is. The question becomes: 'Given that there is no product leader internally to supervise, how probable is it to hire someone that needs supervision (mid-level roles) and have them succeed in their job?'

Andy says: not probable at all.

So the product manager in such situations ends up being the stakeholder idea gatherer, the backlog manager, the dependency handler and the sprint planning story-point-counters (“sooo, can we push for 3 more points in this sprint?”). And that is because they don't have the necessary experience to establish what good product management looks like in the org. Mind you, I don't criticize the tasks (they definitely need to be done), I support that having product managers do them is not how you build successful products (who is going to talk to customers?).

Suggestions for companies

You can see where I am going with this. When a company wants to hire product talent then they should start with bringing in an experienced product leader before hiring product managers.

Now, if there is already a product manager/owner onboard, then things are a bit more complicated. Before bringing any more product talent in, the company needs to assess whether the existing person is capable of taking the product leadership reins and building the right product culture and processes.

This is a key assessment that must be done with a proper competency framework specifically tailored for product management and not just say that ‘he does well so far, let’s give him a chance’. Full transparency will also help the employee being assessed on what their strengths and improvement areas are.

If the assessment is that the capability is there (or almost there), then the employee will need support. Proper training and/or coaching are essential if the product manager is to have a chance of succeeding in their expanded role.

If the assessment is that they don't have product leadership expertise, then the company will need to look for an experienced product leader before hiring more product managers or setting up product teams.

From the candidate’s angle

Looking at this from the candidate's angle, the most important thing that you need to do when interviewing in an early stage company is to speak to the product leader. You need to assess whether they are experienced enough to set the product function for success in the company and also help you become a better product manager.

If there is no product leader present and you are going to be the first product person in the company, then you need to understand that you will need to eventually take on the product leader’s role - whether it is stated or not. If it is stated, then good, things are more straightforward. If not, then it gets tricky as you will be expected to deliver on the product leader’s responsibilities (i.e. enable the product function to succeed in the org), in addition to your other tasks.

The best thing you can do is to openly discuss this with the company leaders to create a common understanding of how it is going to work in practice. For example, are you the first product hire who will then hire more product managers to create a product function? Are you here to take the CEO's detailed direction and write user stories for the team? Are you here because the investor said so? And so on. Be honest about what you can bring to the company and ask for clarity on the expectations.

Parting thoughts

Building products is hard and can be even harder in early stage companies. Bringing product talent to build is a critical step in a company’s life and one that must be made with prudence and clear understanding of the role, if it is going to be successful.

Share

Product management, being a multifaceted profession, requires an extensive set of hard and soft skills. While both are useful in their own way, in my view there is a clear distinction: While the hard skills in product management enable the day to day work to be done, it is the soft skills that enable product managers to have a deep and lasting impact on the business.

Subscribe now

Skills in product management

Let’s start by briefly examining how skills are categorized. 

Hard skills are teachable abilities that are directly related to specific job competencies and can be clearly defined and measured. In contrast, soft skills are more abstract and are also known as interpersonal or people skills.

The list of hard skills required in product management includes requirements gathering, prioritization ability, business and technical acumen, research and analysis proficiency, a basic design taste and so on. It is worth mentioning that the required set of hard skills can vary from role to role, as product management is a practice that differs greatly in how it is practiced. For example, in larger companies there may be different product roles that focus on specific skill sets (the pricing product manager or the technical product manager), whereas in smaller companies product managers have a greater breadth of responsibility.

On the other hand, soft skills are by nature more difficult to quantify. They partly stem from a person’s demeanor and they can also be learned. As all skills they get better by practicing and actively trying to use them in personal or work life.

Product managers typically start by learning the hard skills and they increasingly depend on soft skills to get things done as they progress in their careers.

Let’s go over the most important soft skills for product managers.

Empathy

The best product managers have the ability and desire to get into the shoes of others and see things from their perspective. Empathy is essentially approaching people relations on the principle that it is about them and not us.

Successful products solve important problems. Product managers need to be able to connect with their users so that they can identify what the important problems are along with all their nuances and hidden details. They need to make a habit of actively listening and probing deeper to uncover the root causes behind what appears on the surface.

They need to care for the pain that their customers experience.

There is an important detail however. Chris Voss in his great book “Never split the difference” defines empathy as: “the ability to understand the perspective of a counterpart and the vocalization of that recognition”. Notice that his definition does not dictate to agree or commit to anything – that’s sympathy.

Trying to be empathetic should not be confused with trying to provide solutions for all people’s problems. Being empathetic as a product manager means making an effort to understand what the important problems of users are and why they are happening, so that they can be solved in a way that aligns with the company’s mission and vision.

Effective communication

Closely related to empathy is the ability to communicate effectively. Simply put, great product managers are also excellent communicators.

Building products is a team sport. An interesting metaphor for product management is that it is the glue that binds several departments together in order to solve problems and launch products. A product manager’s ability to communicate is closely related with how effectively they can do this.

Building products is also messy. It is common in organizations for effort to be wasted due to miscommunication when building products. There are usually many people involved, across various departments, each one with their own set of goals and objectives. What makes sense for one may not make sense for the other. And what one assumes as a given may be an edge case for the other. Closing the communication gap in product development falls squarely on the shoulders of product managers.

Moreover, it is very important for product people to take written positions on important matters. Writing things down has the added benefit of being able to take the time to think thoroughly about matters. Not only that but information in written form can be easily followed up and spread around. In contrast, action items assigned verbally in meetings are almost never followed through and corridor agreements have the tendency to be forgotten.

Dear fellow product managers, do not be afraid to over-communicate. No harm can come out of it. As George Bernard Shaw once said: “The single biggest problem in communication is the illusion that it has taken place”.

Self control

Consider the following quote on what a leader is (the addition in the brackets is mine):

“A leader [but also a great product manager] is someone who can project calm in the face of chaos”.

I think that this is very relevant to this discussion, as product management is a leadership function. Let me explain: While most product managers do not have any direct authority over people, they need to be able to rally people in their organizations so that they can make things happen.

Businesses can get frenetic sometimes. New products, new launches, fast changing priorities. Product managers need to be able to have self control and more specifically be able to keep calm in stressful situations, be positive and project dependability. They need to be the voice of reason in their domain. 

Consistently controlling themselves to exhibit these behaviors, will greatly help product managers to control the environment around them in difficult situations, allowing them to elicit positive outcomes out of what would otherwise appear as ordinary mess.

Grit

Product management is hard. If one comes to the profession expecting an easy ride and instant gratification then I would suggest they look somewhere else.

There will be days when things will be chaotic. When your communication will fall on deaf ears and common sense will be an elusive notion. This is usually normal. (As long as it does not happen all the time).

Product managers need to be resilient and be in for the long game, as product success comes from the small day to day wins that accumulate over time. That is not to say that the big wins are not important – they are – but it is the steady pace of the small successes that sets the stage for the big splashes. Product managers should lead their teams through this process, enduring the hard times and continuously push forward knowing that there is light at the end of the tunnel. 

And that takes grit. Grit is defined as: “a positive, non-cognitive trait, based on an individual’s perseverance of effort combined with the passion for a particular long-term goal or end state” (Wikipedia). 

In simpler words, grit is the ability to endure the hardships of day to day while remaining focused on the long term vision. That is exactly what successful product management requires.

Final words

Hard skills enable product managers to effectively manage their products – gather requirements, prioritize requests, do market research and so on. However, it is the soft skills that enable product managers to grow beyond the roles of backlog manager or product expert and have a deep impact on the business.

While there are numerous relevant soft skills to product management, the most important are the ability to empathize, the aptitude for effective communication and the ability to always remain calm and positive in difficult times. Add to these the grit to relentlessly pursue long term goals and you have the foundations for being a great product manager.

Share

The element of trust is frequently quoted as the cultural characteristic that can make or break organizations. More specifically, companies that boast a culture based on trust are known to make better products and retain their employees longer. On the opposite side of the spectrum the lack of trust in the workplace is often connected with toxic cultures.

It isn't just a theoretical idea. Research has shown that trust is connected with organizational effectiveness and performance. And it makes sense. If people in an organization trust each other and their leaders, they will be more creative in solving their differences, they will communicate better and they will be open to work together on promoting each other’s goals. They will be more engaged and less willing to look for work elsewhere.

Subscribe now

Foundations of trust

The foundations of trust are actually simple things: consistency, honesty and clear communication. All elements are equally important but consistency gets a special mention, as trust is built or destroyed with every interaction. As a matter of fact, it takes many positive interactions to gradually build trust and usually only one negative to destroy it.

It goes deeper than that. Take for example the extensive study that Google conducted over the span of two years, where they tried to find out what are the key traits of effective teams. Using data from interviews with over 180 teams they found out that the top traits of successful teams were psychological safety and dependability. The reasoning behind the result was that the safer team members feel with one another, the more likely they are to partner to deliver results, take on new initiatives, talk about failures and how to prevent them.

How is the element of trust connected to this? Trust is the backbone for both of these two elements. For one, trust between team members and their leaders contributes to psychological safety (and vice versa). Second, being known as dependable is all about others trusting you that you will do as you say.

Trust as an agility enabler

All this sounds nice but one could argue that they are mostly theoretical. So, what are the positive effects of trust in practical terms?

It boils down to this: Trust is a huge enabler of agility in organizations.

The ability to move closer to a just-in-time model where decisions are made quickly with minimal bureaucracy depends directly on whether the different groups in an organization trust each other to deliver and have their back when the need arises.

This concept is often expressed as the trust-communication trade off. It goes like this: The more that team members trust each other the less communication is required to achieve something collectively. Ben Horowitz, in his book “The Hard Thing About Hard Things”, writes: “If I trust you completely, then I require no explanation or communication of your actions whatsoever, because I know that whatever you are doing is in my best interests.”

In order to better demonstrate the relation of trust and organizational agility, let us briefly consider how the lack of trust between people and teams affects organizations.

A characteristic of environments where there is no trust between people is that teams and individuals routinely spend extra effort to make sure that they have the necessary elements in place to protect themselves in the event of a screw up. In this us-versus-them way of thinking, people often do not see other departments or groups as being in the same team but rather as opponents with conflicting goals. This is a killer of great products and only it serves to reinforce the silo mentality that is often ingrained in the culture of larger organizations.

If you are working in a corporate environment for some time, you will probably be aware of the practical manifestation of the silo mentality: handovers. Handovers are arguably one of the most important impediments of agility in organizations. We all know how it works. There are the handover policies, the relevant handover documents when a task is completed and a sign-off process to signal that this part of the work is done. We did our work, so now you do yours. Not our problem anymore.

Apart from the time spent not actually building the product or doing discovery activities, the real issue with handovers is the lack of shared responsibility behind the development of products. Simply put, handovers are agility killers.

How product leaders can contribute in building a culture of trust

Like many other culture related elements, it is the leadership of an organization that sets the tone on how people should interact with each other. A culture of trust starts from the top and specifically with leaders acting as role models in their everyday interactions.

Here is how product leaders and their teams can contribute in building an organizational culture based on trust.

Bridging the gaps

The product management function sits in the intersection of different departments in an organization - operations, sales, marketing and so on. As such, product leaders play a critical role in bridging the gaps between the silos and crafting a culture of trust.

Every department in an organization has different needs and goals. Sales want responsiveness in their requests. Marketing wants better tools to track product performance in the market. Operations want a crystal ball that can diagnose any product related problem in production.

Product leaders should advocate not turning people down by default when they request something. Practice empathy and listen to their point of view. What does each department want? Why? How can we help them reach their quarterly or annual targets while making sure that we are building our products with the long term vision in mind?

Data trumps opinions

It should go without saying but leaders should mandate the use data for decision making. Moving discussions from opinions to data brings trust-building objectivity into the process.

Asking others to trust you because of what you think will usually be met with resistance, especially if you are not seen as an expert in the specific field. And in the event that they do and you are wrong, then good luck to have them trust you again. Instead, providing data that backs your opinion opens the door to fruitful cooperation that over time builds trust among teams.

As product people we should also be ready to reconsider our point of view if the data does not support it. Strong opinions, weakly held. Making a point to always validate one’s own assumptions with data minimizes the chances of falling victim to confirmation bias.

Owning failures

Product leaders should own their teams’ failures and ensure that the organization learns from them. This is an element that is often missed and has the dynamic to break the trust of people in the organization, not because of the failures themselves but because of how they were handled.

Crisis management experts advocate: “Don’t waste a good crisis”. Times of great stress are actually opportunities. They are opportunities because if handled correctly, they have the capacity to set an example, to show that the organization can learn from its mistakes and to set a precedent of being able to trust one another to have their back.

Or, if handled incorrectly by playing the blame game and taking CYA (cover-your-ass) positions they can destroy trust in the organization and its leaders.

Instead of playing defense after a crisis product leaders should be able to come forward and say:

“We screwed up. Here is why it happened and here is how we will make sure that it does not happen again.”

Of course they must make sure that their teams execute on this promise. If they don’t then it is just another broken promise that only serves to undermine their trustworthiness.

Trust the product manager

Another very important aspect of product leadership is building trust in the product management function itself. Product management is highly varied work and sometimes it can be hard for people in the organization to pinpoint how exactly the product manager adds value. A typical product manager is usually always busy, going from meeting to meeting and dealing with 3 or 4 things at any given time. But someone might wonder what exactly is it they do that adds value?

Product leaders should be the chief advocates on why product management is essential for long term product success. They should explain in practical terms how product managers lead the discovery process, help facilitate decisions, fill the gaps between stakeholder groups and promote a holistic vision of what success looks like for the product.

Product leaders can also reinforce trust in product management by being overly transparent. There are various ways. Share openly what the product teams do and why. Share what each team is learning from their experiments. Explain how the product function works internally. Many product managers boast that they lead by example and this is an excellent opportunity to put their money where their mouth is and become a role model for the rest of the organization.

Teamwork > individual performance

And the most controversial of them all: Leaders should take a critical look at anyone who is consistently damaging trust due to their behavior in the organization, even if they are top performers.

It doesn't matter if an employee performs great as an individual or “gets things done” if they are demoralizing their coworkers in doing so. Building products is a team sport.

Accepting toxic behavior just because someone delivers short term results effectively damages the organization's ability to deliver on the long term.

You can be sure that any incidents of such behavior will be already discussed in the office corridors or during lunch by the time that you learn about them. Bringing them to light and dealing with them appropriately sends a very clear message to everyone in the organization that they are not acceptable. Respectively, not doing anything and letting trust-eroding behavior persist sends a message that this is how things work around here.

Final words

An organizational culture that is based on trust enables people to work with each other more effectively, spending less time to protect themselves from blame and be more open to taking risks. It leads to more engaged teams that have the ability to respond faster to change and can go through the rigors of product development with a sense of shared responsibility.

However trust is fragile. It takes consistent effort of being honest and communicate openly to build it and usually only one incident of contradicting behavior to erode it. Leaders should be regarding themselves as role models, taking every opportunity to promote trust building behavior, as well as condemn trust eroding actions.

Because after all, this is not just a theoretical idea. It has been proven time after time that a culture of trust leads to more agile organizations that can react faster to market changes and ultimately produce better products.

Share

In product development there are certain considerations that will routinely need to be made when creating or changing products: How much does this change cost? What is the effort required for this update? How fast can we deliver this set of requirements? These questions are the bread and butter of a product manager. Yet there is a common factor that affects the answers to all these questions: the underlying complexity of the product or system at hand.

Complexity tends to breed more complexity, as changes in complex systems are complex themselves. Think of it as a vicious circle that once it begins is very hard to reverse, as there is a debt to be paid to undo complexity. A debt that only increases with every change that does not specifically serve to simplify things.

Subscribe now

Complexity in software products

Complexity in software products is created when the default problem-solving activity is to add functionality and can creep in:

• the user experience – the part of the product that customers see and interact with, thus making the product harder to understand and use

• the underlying system – this can be complexity on the code level or in the way that the different subsystems interact with each other, making the product harder to maintain and troubleshoot

• on a process level – for example in the processes to deploy the product, gather customer feedback or provide customer support

Using a physics analogy, think of complexity as the entropy of a system. Every change in a system (or product) that is not done specifically to reduce entropy (or complexity) only serves to increase it. Increased entropy makes a system unpredictable and hard to control.

Similarly, increased complexity makes for products that are a) hard to maintain, b) have longer go-to-market times and c) offer a poor user experience.

Complexity makes for products that are hard to maintain

The real cost of complexity is paid in the mid to long term as complex products are harder to maintain. The time that was spent implementing “just one more” feature to reach a short term goal is usually a fraction of the time that is needed to maintain this feature in the long run.

This time does not only involve engineering time (i.e. actual time coding around the complexity of the system so that a change does not break it down). It involves other aspects too, like the time needed to troubleshoot issues and respond to customer queries.

Troubleshooting time tends to increase exponentially with increases in product complexity. Anyone involved in troubleshooting issues in a very complex product will know what I mean. They will remember the frustration of the people involved as they strive to understand what is going on and questioning (maybe loudly) why the system is ever so complex.

Excess complexity also affects the time needed to properly document and communicate how the system works. A system can be properly documented or it can be under-documented. Both states are problematic for a complex system. Let me explain.

Obviously, an under-documented complex system is a time bomb waiting to explode. But over-documenting complexity is not a silver bullet either. In this case there would be an enormous amount of documentation that stakeholders will need to read and understand. Guess what will happen when they will need to troubleshoot an issue or support a customer under time pressure: they probably won’t read or understand it (at least not in its entirety). And mistakes will be made. That will require more time down the line to fix. And so on.

Complex products usually ship later than sooner

Complexity breeds risk. And risk is the bane of all project plans.

Complexity induces risk in planning in two ways. First, it is a nightmare having too many moving pieces on the board and trying to work out the inter-dependencies between them when trying to create a launch plan. Second, having each separate item on the plan come with risk attached on the delivery date only makes things worse.

Consider the following dialog excerpts:

• Q: "Will development on this item be completed by the end of week?"

  • A: "Not sure, as the code is very complex and the engineers are trying to cater for all the edge cases."

• "Will we be able to finish the requirements analysis in X days?"

  • A: "Not sure, we need more time because the system is complex and the business analyst needs to align with all the affected teams to make sure that we do not miss anything."

Imagine trying to create a project plan with the above. Add to that the communication overhead that a complex system causes when trying to get everyone on the same page and you get the idea.

Adding complexity is a sure way to jeopardize your launch dates.

Complexity leads in poor user experience

Complexity in software products tends to surface on the user interface. Complex user interfaces require more effort to understand and use and amplify the possibility to make mistakes.

Steve Krug in his famous book “Don’t Make Me Think” advocates that more you make people think when using a software program or web site, the more likely they are to go elsewhere to get the job done. I strongly believe that this is true.

A complex product that attempts to do too many things rather than a few things very well will result in users looking for simpler alternatives that cover their needs better. If the value proposition of a product is not crystal clear in the minds of the users they will often have a hard time justifying their investment in that product. There are numerous examples of products that have offered streamlined user experiences and have won over more complex alternatives (for example Apple’s iPod).

An over-complicated user experience will drive users away from your product. Especially if there are simpler alternatives available. Or even if there currently aren’t any, then you are presenting an excellent opportunity to your competitors to disrupt you by offering them.

Keeping things simple

The best preventive measure against complexity is to actively guard against it and try to keep things simple where possible.

Make simplicity a key design principle for your products, in the user experience, in the technical level, in its processes.

Whenever trying to come with a solution to solve a problem take a step back and ask: ‘what is the simplest solution to solve this’? It could be to remove a step in the user flow instead of adding one. Or change a process. Or even a complete redesign of a complex technical setup.

Software systems are inherently complex and it is not realistic to expect that you will be always able to avoid complexity. However, unless you actively seek simplicity in your designs then you will almost always end in the opposite side of the spectrum.

Change your planning language

Build your roadmaps using outcomes and not features. If you organize your product building efforts using features then you are actually prescribing complexity. Think about it: when talking about features you typically use the verb ‘add’ (i.e. add a feature). Constantly adding features to solve problems leads to feature overloaded products.

However if you build for outcomes then you effectively decouple the implementation (the feature) from the solution. Instead of planning for features to solve problems a better approach would be to examine the outcome that needs to be achieved and plot the simplest path to get there.

Reducing the complexity debt

Making sure that no excess complexity is added is one thing. Most mature systems however should have already accumulated a sizable amount of complexity debt. Time should be frequently reserved to examine the system and identify areas that could be further simplified.

This practice is akin to reserving time to reduce technical debt in code. However, in this case you would be reducing the complexity debt that has accumulated over time, in the form of streamlining the user experience, the existing product processes, the user interface, the infrastructure setup and so on.

This action can be part of a wider continuous improvement initiative that may exist in the company and not as a standalone effort. Attaching it to a more generally accepted and endorsed work stream will often enable easier justification for the effort spent on it, especially if the company’s focus is on short term results.

Final words

Dealing with complexity in product development is easier said than done. It is in the natural state of things that any change to a system only serves to make it more complex, much like the entropy analogy.

It would be naive to hope to eliminate complexity altogether, as software products are complex systems by definition and tend to get more complex as they evolve and mature.

However, if you do not take a vigilant stance and guard against complexity, you will often end up in uncomfortable situations where it will be very hard to push the needle, ridden by complexity debt that needs to be paid in order to move things forward.

Share

The world is full of examples of well engineered products that have failed to make an impact. What is common to them is that they failed to resonate with customers because they lacked the delight factor – the capacity to offer delightful user experiences.

Such products can feel like a collection of features rather than a product with a focused value proposition. Or if this is not the case, it may be that their value proposition is based on weak assumptions that do not hold true in real life.

I think that the way that product teams are organized can contribute hugely to this problem.

This is because product development teams are often optimized around software delivery or optimal resource utilization. In a poor interpretation of what Agile really is, teams in many organizations are set up to to focus on delivery and miss product discovery.

Subscribe now

What’s the Problem?

The problem is that you get what you optimize for.

If you optimize for software delivery and optimal resource utilization then (in the best case) you will get exactly that.

What you are not guaranteed to get, is an extraordinary end-to-end customer experience.

Take this example. In a company where there are multiple product development teams and each one has a product manager, there is a meeting about a feature that touches many product areas. More often than not, there will be many product managers present, each one standing up for their own product area of responsibility.

But who among them truly owns the end-to-end user experience?

This statement by computer programmer Melvin Conway in 1967 is very relevant (it’s known as Conway's law):

"Organizations which design systems… are constrained to produce designs which are copies of the communication structures of these organizations."

Melvin Conway

In our example that would mean a user experience that mirrors the communication mess between different teams. If there is no true ownership of the user experience then the result will most probably be a disjointed product, like taking multiple pieces and stacking them together.

If you optimize for software delivery, the product development teams may be efficient, have optimal resource utilization, and produce clean software quickly. However that will not matter if they are not building the right thing.

Organizing Around Customer Experiences

An alternative worth exploring is to focus product teams on producing exceptional customer experiences.

There are two basic ingredients needed for this. The first one is cross-functional teams with skills that span components and technologies, also known as feature teams. Such teams should be responsible to take ideas from inception to validated customer value.

There is a second element that is often missed. Note that I did not say “from inception to implementation”. In many organizations an addition or change to the product is considered completed when it has been designed, coded, tested, and delivered to production. But just because a feature is in production does not mean that it is finished.

Product managers who think this way miss the understanding of whether that particular feature should have been included in the first place. Is this particular feature furthering the product mission or is it just adding to the feature clutter?

But even if we accept that the original idea was in the general right direction, is the form that it was delivered in the best and most effective one? The truth is that this will not be known until it gets measured.

So, lean startup thinking has a place even in non startups. Using the “build – measure – learn” mentality to guide product development is a powerful way of iterating towards actual validated customer value.

Going to production should be the first step in order to get the feedback loop working. From there the teams should view their delivered work as an enabler for the discovery phase that will allow them to validate the original idea and optimize the customer experience.

Practical Issues

Having teams that touch many product areas and components inevitably leads to many planning and integration issues. Planning and integration may be easy with one product team but it will become exponentially hard as more teams are added to the mix. Dealing with such issues inevitably takes up a lot of time.

There will also be challenges in the technical decisions about individual components. If no team is dedicated to evolve a component, then who has its technical ownership? There is a danger that, in a complex setup of many teams and even more components, the evolution of individual technical areas will follow a Frankenstein pattern, where every team adds what they need to each component they touch until it becomes non-maintainable.

In addition, if two separate teams work on two different experiences there is the possibility that there will be different approaches on how to deal with specific features in the product. Product managers should be proactive in their communication and constantly in sync so that they can take joint decisions early on such issues.

All this means that, in order to optimize for user experiences, teams will have to sacrifice some of the efficiency in delivering software.

It’s important to bolster horizontal communication and push for constant inter-team synchronization so that issues can be addressed early. Product architects who work in cooperation with the teams will need to drive the hard decisions about how the architecture of each component will evolve. Horizontal functional groups will need to be formed so that expertise and best practices can be spread across teams. Product managers will need to make sure that they over-communicate and are constantly aligned with their peers. And all this takes time.

Is There a Silver Bullet?

There is no universal organizational setup that works everywhere. Anyone who claims that they have a “best-practice” product team setup that can be blindly adopted is either misinformed or lying.

You have to go through the hard work of discovering the best setup for your organizational context. It is important to have clarity on the purpose that you are organizing your teams for. Are you organizing for delivery? For product discovery? Both? Or are you just copying what someone else did and hoping that since it worked for them it will also work for you? (hint: it probably won’t).

Along with the purpose, there are also many variables that need to be considered: company and department size, company culture and how it has evolved over the years, the presence of experienced people who can assume leadership, and so on. Executive sponsorship is also vital.

You must not assume that once a good setup has been found – or even one that doesn’t suck – that you are done. As the company and its people evolve and mature, so will be the optimal setup for organizing their work.

A Step Further

One way to think of this would be to treat the exercise of organizing product teams as a product itself.

This may sound like a stretch, but bear with me. Consider the following marketing adage (which I like very much): “People Don’t Buy Products, They Buy Better Versions of Themselves”. In that sense, where the product is the organizational structure and the consumers are the employees, we could draw the analogy that:

“A successful product organizational structure is one that helps team members to thrive and grow in their work while producing better products.”

An interesting proposition. Along with the intentional team setup, there are two elements that need to be present for this to happen.

The first one is the product discovery feedback loop that fuels the “produce better products” part and it starts with a culture of validating assumptions and ideas. To that end, there should be opportunities for product teams to get close to the customers for real end-user validation. Teams should continuously invest in product discovery and validation activities and treat everything as an assumption unless proven otherwise.

The other is an organizational culture that enables the “thrive and grow” part. Products are built by people. And people evolve and mature. As a product leader you have to foster a culture where there the focus is on personal and professional growth. Keep in mind that your “A-players” will definitely and relentlessly pursue their growth and they can do it either in your company or in a competitor.

Is That all?

Not quite. I said that it doesn’t matter if your teams are optimized for software delivery if you are not building the right thing. While there is truth to this, the reality is a bit more nuanced.

It does matter that you build the product right, otherwise you won’t be able to change it fast enough according to the feedback you get. And changing and iterating will ultimately lead you to build the right thing.

So you need to be focused on delivering extraordinary customer experiences while also striving for delivery excellence. There is no black or white solution – the best way is somewhere in the middle and will be constantly moving as your company evolves.

In other words, you have to organize your teams so that they can build the right thing and build it right.

Difficult? Definitely. Worth trying? Absolutely.

This article was originally published on Mind the Product on February 2019.

Share

As product managers we make decisions all the time. What the priorities are, how to deal with a particular problem, how to motivate the team and so on. When we do, we like to think that we are objective and that our decisions are the outcome of rational thinking.

Unfortunately, cognitive biases often meddle with our decision making process, leading to poor decisions and bad judgment calls.

Subscribe now

What is a cognitive bias?

First, let us establish what a cognitive bias is. A cognitive bias is defined as:

“a systematic pattern of deviation from norm or rationality in judgment” [1].

The key element in this definition is the word systematic, as cognitive biases cannot be turned on or off, sometimes affecting our view of reality and sometimes not. Instead they constantly influence human judgment so that reasoning errors are reliably produced.

It is critical for product managers to be aware of cognitive biases and how they work, as they can steer product decision making away from data informed, rational argumentation.

Some of the most common types of cognitive biases for product people are the following.

Confirmation Bias

Confirmation bias is the tendency to seek answers that validate our beliefs and discard information that do not support our views.

In other words when a person hears only what they want to hear. It is especially problematic if that person is a product manager, as confirmation bias essentially limits their field of view and suppresses their objectiveness in the decision making process.

For example, when getting user feedback a product manager may pay more attention in reported issues that fall in line with their personal experience of using the product. Or a product manager with a technical background may have a preference to a technical solution that they are more familiar with. In both cases objectivity goes out of the window.

Overcoming confirmation bias takes being open to other views and accepting the uncomfort of eventually being wrong. It is a fine line to walk on, as product managers need to lead with conviction and be right a lot, so that they can earn the trust of others and make things happen. However, being too confident on one’s own views can reinforce the effects of confirmation bias, so keeping an open mind is strongly advised.

It also helps to be careful to avoid prescribing solutions to problems, even unintentionally. For example, a practical approach when talking to users would be to avoid asking: “How likely would you be to use this product/feature?” Framing the question this way nudges the user to think along the lines already presented. Instead ask users to describe in their own words the problem that they have. Thoroughly exploring the problem space before moving to the solution space will help to avoid prematurely prescribing solutions that validate our way of thinking.

The Sunk Cost Fallacy

The sunk cost fallacy occurs when people refuse to abandon a non viable endeavor that they have invested considerable effort in.

Consider the following situation: a product or project that month after month does not hit the mark, but instead of killing it more resources are poured into it in an effort to make it work. The reasoning behind these decisions is that since so much resources have already been spent, it has to work so that all this effort and money is not thrown away.

The key point is to be able to accept when it is actually time to quit something. It is not easy, as discarding a project is essentially admitting that a mistake was made in spending effort on it. But acknowledging a mistake is the first step in the process of fixing it.

There is not a clear-cut methodology to follow when deciding whether to push forward or whether to pull the plug on a non viable product. Such issues usually span beyond the decision making power of product managers themselves and are influenced by the overall business strategy. Organizational politics and personal egos also play a role. Getting this right can be a career booster (and likewise getting this wrong can be a career staller, at least in your current company).

A data driven approach, good knowledge of the market and the specific domain and alignment with the overall business strategy are advised for such cases.

Survivorship Bias

Survivorship bias is the tendency to draw conclusions based only on what has worked in the past (ie. has “survived” a process) and ignoring what has not.

Under the effects of survivorship bias one aims to harvest the winning elements of past wins, subconsciously (or not) trying to reuse the same formula for success. However, this line of thinking ignores the fact that a past success may be due to luck or that it was influenced by different environmental conditions. The different conditions depend on the specific context and could range from market related like competition maturity or pricing, user related like different user segments or cohorts, organizational related like different team dynamics and so on.

Thinking this way also pushes away the opportunity to learn from past failures, opening the door for the same mistakes to happen again.

For example a product manager under the influence of survivorship bias may concentrate only on current users of their product (that have “survived” the onboarding process) and ignore churned users. Doing so they miss the opportunity to learn why the rest users chose not to continue using the product and the possibility to get insights on how to reduce the churn rate. Or they may support a specific solution to a problem that has worked for them before, disregarding the fact that the context of the problem or the conditions may be different.

The Curse of Knowledge

The curse of knowledge occurs when an expert on a topic assumes that other non-experts have the background to understand.

This is a phenomenon very relevant to senior product managers who live and breathe how their product works and often assume that users have a comparable level of knowledge about it. A product manager affected by this cognitive bias could wonder when facing users that have trouble using it: "Why don’t they get it?", forgetting that all the product exposure that users may have is a superficial view of the main screen and (maybe) a glimpse of the manual.

Another aspect of this effect is that product managers often tend to favor feedback from their advanced users. Advanced users can understand the intricacies of how the product works and can engage in deeper conversations about it. Product managers have an easier time communicating with someone who can “speak” the same product language, without the need to explain the basics. The result is that more effort is directed towards meeting the needs of advanced users, increasing complexity and making the product more difficult to use for new users.

To overcome the curse of knowledge product people need to practice empathy when talking to users. They need to consider the level of product knowledge that users have and adjust their communication for their specific level of understanding. It is important to understand that users have different needs depending on where they are in their product journey. Disregarding the needs of a specific segment, for example new users, will prove detrimental for their experience and will turn them away from the product.

Final words

Cognitive biases have the potential to affect decision making in ways that are difficult to discern. When they do, it is often hard for the affected individuals to accept that their way of thinking is systematically affected. Product managers as decision facilitators are especially prone to be affected.

Fortunately, there are actions that can be taken to minimize the detrimental effects of biases. The first is developing awareness. Being aware of what cognitive biases are and in what way they can affect judgement is key in the process of overcoming them. The second is vigilance. Actively monitoring against common biases will help to detect biased decision making early, allowing to course correct before any major damage is done and minimize the impact of any cognitive bias at play.

References: [1] Haselton, M.G., Nettle, D. and Andrews, P.W., 2015. The Evolution of Cognitive Bias. The Handbook of Evolutionary Psychology, pp.724-746.

Share