Building an MVP and launching a product is actually the easy part. It’s much more difficult to manage a product in its maturity or decline stages, so I wanted to tackle the challenges of a product that’s past its initial growth stage, and share some tips on:
– How to avoid becoming a feature factory, while taming your beast of a backlog
– How to use your roadmap to drive experimentation to hit company objectives
– How to disrupt yourself before someone else does
The Product Lifecycle
We all know the product lifecycle chart. While many of us are familiar with the uphill battle and the grind involved in getting traction and any growth towards product/market fit, the launch and growth phases represent a small fraction of the overall life of a product.
Product Life Cycle
The MVP and initial fast iterations and pivots we usually talk about? That usually happens at the very beginning. But in reality, it’s not where most product managers spend their time. Most product managers have adopted an existing product that’s closer to the maturity end of the chart; one that has a pile of existing customers and constraints, a good chunk of tech debt, and invariably a messy backlog of features and bugs that they’ll never be able to fully work through.
But if you look at sales volume, it’s at this maturity stage where most of the money is made. And it’s at this stage where churn really starts to hurt. After all, it’s easy to hide an ugly churn rate when you’re whipping up fast growth, but it’s a mathematical fact that any churn rate over 0, as you begin to saturate the market, will eventually flatten this curve out. It’s when your product is mature that churn really starts to bite back.
And yet if you look at what you typically read on Medium and other startup-savvy publications, you’ll mostly read about launching products and optimising for growth. No one seems to write about managing products that are reaching maturity, or god forbid, the decline stages.
Which is a shame, since it’s exactly at those stages when things start to get really hard.
The reality is, if you want people to use your product long-term, your product will have to grow with them.
Each day that your product is in existence, the people who use it change and progress. They get accustomed to how it works and fold it into their processes. They get better at using it, and develop needs for more advanced usage.
And with each day, you have new people entering your world as first-time users. This is great for growth, but they represent an entirely different sort of user.
When we first launched ProdPad, our users were simple: early adopters who were eager to try a new product and happy to put up with being beta tested on. They gave prolific feedback and built relationships with our team. Happily, some of those users are still with us today, but their needs have changed entirely. These days, they proudly show examples of how they’ve built their processes around our tool, are adept at instructing others (and us!) on how to use it. They regularly ask for an increasingly complex set of features to fit their advancing needs. They’re the same people they were several years ago, but represent different personas now.
And yet new users join each day. These are people who’ve never tried the product before and don’t know their way around. And unlike the early adopters, they come out of the gate with higher expectations than the folks we encountered years ago.
It’s like having to build two different products at the same time.
In the growth stage, your team is focused on getting product/market fit. It’s about cracking those quick wins and boosting the wow factor. Whatever it takes to get traction and prove your product has a place in the world.
In the maturity stage, you’ve got existing and new users to build for, built-in constraints and technical complexity, politics and people to work around.
Maturity Comes with Problems
Problem: You’re a Feature Factory
If you’re a maturing company, you might find that you’ve become a feature factory. This often grows out of old habits that were once good, but are now misguided. In the early stages, each new feature brought more downloads, signups and sales, and blasted you forward beyond the competition. You were hyper agile and pushed code and new features weekly, if not daily! You out-paced your competitors, and know how to move fast.
But in the later stages, the goal isn’t to just deliver features! In fact, each new feature weighs you down, resulting in a Frankenstein of a product. Your old agile habits have led you astray.
This is why it’s so important to think objectives, not features! In order to survive, you’ll need to have a renewed focus on hitting company objectives and solving real problems, instead of just delivering features. Inherently, teams understand this. They know that a big pile of features isn’t what their customers want or what their business needs. And yet it’s a pattern that happens over and over again.
I blame the roadmap. Roadmaps aren’t inherently bad… in fact, they can be a remarkably effective tool for communicating product strategy! And yet, a badly done roadmap can pave the way to a feature-filled product death.
Timeline roadmap format – designed to fail (and not in the good way)
So I implore you all to do this with me: Ditch your timeline roadmap.
Sure, this format of the roadmap makes you look good today… your board and your boss love seeing this level of certainty nailed to the wall. but it’s setting you up for failure.
See, the problem with a typical roadmap is that it pits Time vs. Things to do, with Time represented on the x-axis, creating this timeline along the top. That’s all well and good at first, especially when you’re representing your short-term projects and your upcoming releases, where your team has given decent estimates and is on board with the given release dates. But the more you add to the roadmap and the further down the line you get, the harder it becomes to manage.
Soon, you end up with a pile of features, each with given durations and due dates, implied simply from the very layout of the roadmap, with that timeline, ever marching forward along the top. And we all know that these aren’t tightly estimated, fixed-scope projects. These estimates and due dates are coming out of assumptions piled on top of assumptions.
You assume you know how long each of these features is going to take. This game is easy in the short term, when you’ve got a clear undertanding of what the developers on your team can take on and they’ve helped you craft your estimates, but the further out you go, the less you’re going to be certain.
You assume that nothing else is going to come in and disrupt this timeline. No changes in the market, no new competitors, no fresh ideas coming from customers, no need for iteration.
You assume that each of these features will work as soon as they launch. You allowed three weeks to build that checkout page? Then at the end of three weeks, it’ll be converting exactly as well as expected, and now you’re free to move on to the next thing.
You assume that each of these features actually deserves to exist! That they form part of the strategy and therefore should be codified.
Overall, you’re making one big, dangerous assumption: That nothing is going to change. What could possibly go wrong?
This pile of assumptions could lead you towards a bunch of unhappy times. The made up release dates end up sending you and your developers on death marches, trying to meet the deadline. Your sales team and your customers have set expectations on what’s going to be delivered and when, while you’re missing market opportunities and possibly even building entirely the wrong things. This all makes for sad product managers.
So is there a better way?
3 Steps to Ditching Your Timeline Roadmap and Getting out of the Feature Factory
Step 2: Map out your objectives. These are outcome-based goals that are tied to your company strategy. You might know them as KPIs or OKRs, or just as Objectives. It doesn’t matter what you call them – whatever works best for you and your team. Your objectives act as guardrails to keep everyone pointing in the same direction and working on the right things.
Step 3: Change out your timeline for time horizons. It’s subtle, but instead of a single line marching forward, think in terms of these three buckets:
The future column is less about specific initiatives, but more around outlining the problems that you think need to be solved in order to fulfil your vision, but still need to be validated.
And that’s key: your roadmap is for validation. Your roadmap is a prototype for your strategy.
Just as you might validate a feature by drawing up some paper prototypes and showing them to your customers and then starting again based on the feedback, your roadmap is a starting point for conversations around what needs to be included in your strategy.
Result: Lean Product Roadmap
By putting these three elements together – your vision, your objectives, and your time horizons – you can build a Lean Roadmap.
Lean Roadmap (Stacks)
Lean Roadmap (Streams)
The value of this roadmap format is that it takes the focus off building features and hitting delivery dates, and helps your team strive towards solving problems.
Problem: Your Backlog is a Beast
Nothing stifles innovation like a to-do list as long as your arm. And yet this is a state that so many teams get stuck in. In their Trello board or their JIRA wall, they can work through a handful of tickets at a time, and yet there’s always a massive, bloated, vertigo-inducing column of tickets that are lined up to do next.
It stresses out the development team who are looking down the barrel of a million upcoming tasks, many of which aren’t even properly defined, and it freaks out the non-tech team who are just wondering why none of their ideas ever seem to see the light of day.
The solution is remarkably simply. Break the backlog up into two parts: The Product Backlog and the Development Backlog.
Here’s where a lot of people get confused, because “backlog” is a broad term. Here’s what I mean by each:
Development Backlog: A small list of self-contained and estimated specs, which are approved for development, prioritised, and ready for the next available developer to pick up and crack on with.
Product Backlog: A list of all of the things you could do. You’ll never complete everything on this list, and it’ll always be in a constant state of flux. It’ll include customer requests, suggestions from your team, through to insights from your experiments and prototypes. It should be accessible by your team, to both contribute and follow along on progress – your team should be helping to build and flesh out the ideas in your backlog. This is your space to prototype and spec out ideas, map them to your objectives, and track their progress until ready for production.
A tidy development backlog is crucial for solid execution, while a transparent product backlog is key to your strategy. Split your backlog into these two parts to avoid having a beast of a backlog and not getting the best of either world.
Problem: Experimentation Scares you
We’re all familiar with the Build-Measure-Learn cycle. It seems simple; it is simple. That is, until you’ve got competition nipping at your heels, a growing base of customers asking for more and more, tech debt creeping in at the edges. Your company enters a panic mode, trying to shovel features and fixes out the door, and neglects to focus on anything other than the Build part.
They forget the other two parts of the flow: Measuring and learning!
And so instead of Build-Measure-Learn, this becomes Build-Build-Build, also known as the Build Trap.
It important to battle this urge to build constantly, especially as the product matures. The key thing that’s often missing is simply creating the time and the space to validate the work that’s being done. It’s not that people in the team don’t understand it’s important to make sure that the right metrics are moving, it’s that they often don’t have the permission and time to stop building, and actually do the measurements.
One solid way to do this is to adopt some form of dual track agile. There are a lot of ways to interpreting dual track agile, but the essence is that you give figuring out what to build as much importance as the building process itself. You start with a discovery track to find out if a product idea is good and if it makes sense to build. Successful findings from the discovery track are added to the backlog of the delivery track.
Dual track agile
Having a dual track approach gives you permission to spend the time in discovery, instead of feeling the pressure to constantly deliver. Done well, this gives you the best combo of speed and learning.
Don’t trash your roadmap!
I see a bad habit all the time: You’ve released something, so then you close all the tickets in JIRA, crumple up all the sticky notes on the wall, and start moving on to the next thing. This might seem good for keeping up cadence, but bad for ensuring that you’re making an impact.
After all, just because something was launched, doesn’t mean it’s solved the problem you wanted it to!
Experimenting on a lean roadmap
Fortunately, your roadmap can help give you this space. As I showed earlier, each card is a problem to be solved, and is tied to an objective.
Each card, will in turn, be connected to a list of experiments that could be run in order to solve that problem, and impact that objective.
You can use your roadmap to give you an overview of progress on ongoing experiments. And once a project is done in development, don’t just throw out these results or tuck them away somewhere you’ll never find them again…
Instead, move them to a list of completed cards.
Validating on a lean roadmap
The purpose is to give you a space to track what was released and when, and then outline the results. Did it solve the problem and move the metric you were hoping it would?
By making the Completed section of the roadmap a part of your process, it provides a space to show off the value of the work done.
You know nothing.
It helps to remember that it’s not your job to have all the answers. You’re supposed to know less than your colleagues. Instead, focus on asking the best questions, and creating a safe space for everyone to contribute.
It’s important for a team, at any stage of the product life cycle, to have psychological safety. This is about making people more comfortable about speaking up,
reporting errors, and pitching in to help with the product.
You can help build this safety within your own team with just a couple tweaks to your language which will help create the right environment:
How might we? Phrase questions so they begin with “How might we…”. It turns the issue into a collective problem; it supposes instead of asserts. And it works really well in conjunction with:
I bet… As a product manager, you’re going to be wrong, a lot. “I bet” gives you permission to fail and try again. After all, it wasn’t you that was wrong
– it was your hypothesis. And now that you know what doesn’t work, you’re free to test the next bet.
It’s subtle, but these tweaks in process and shifts in language set the stage for psychological safety, allowing you to build more confidence in the experiments you’re running.
Problem: You’re About to be Disrupted
If you’ve been so tenacious and lucky to end up with a mature product that’s spinning cash, you can be sure that you’ve got some fleet-footed startups right on your heels.
Most companies start off on the far end of this scale, where they’re incredibly nimble. They don’t have customers yet, there’s no tech debt or other impediments to iterating quickly. The founders have read Lean Startup and are ready to use it in anger.
On the opposite end of this scale, you’ve got your giants. Slow-moving, risk-averse organisations that are pinned down by government regulations and obligations to their vast pool of stakeholders. Slow or not, these organisations often don’t have an immediate incentive to become more nimble. Those regulations are a barrier to entry for other companies, and the value they add to their existing shareholders translates to massive piles of cash. It’s nice to be at the top.
But the competitive field is always changing. Upstarts are always chewing away at the edges, taking advantage of loopholes and new technologies to capture small parks of the massive market. Larger, slower companies need to be on the watch out, or else those new products will eventually render their mature portfolio obsolete.
The shift from nimble to slow is pretty much inevitable for any maturing product, but the most successful companies have found ways to compete with these upstarts.
They need to disrupt themselves before someone else does.
I’ve surfaced four models for doing so:
The Google: Google is famous for its 20% time. It gives staff the equivalent of one day per week to work on whatever they like. It might seem..
I introduced a concept called Product EQ when speaking about managing conflict at work at a recent ProductTank London. It’s a term that focuses on the emotional intelligence / emotional quotient competencies that were introduced by Daniel Goleman and remain essential to our craft such as influencing, teamwork & collaboration, leadership, organizational awareness, and empathy. All of these skills are just as crucial to product success as roadmap building, A/B testing and OKRs, however they’re often not given the emphasis that they deserve.
Over the next few months, I’ll be writing columns that further explore and encourage the awareness of Product EQ. Below is the first – an overview of my talk about conflict management and an intro to Product EQ.
Let’s Start With a Scenario Many of you Will Have Experienced
Meet Sue and Tom. Sue is an engineering lead on a team and Tom is the product manager. They work at an AI start-up and have recently been focused on a new piece of functionality that is going to put their company on the map… It’s going to disrupt the entire industry! The potential is HUGE!
Not surprisingly, Tom, Sue and team are under a lot of pressure to get this world-changing product out the door. Tom is pushing to meet a certain date to beat competition, while Sue is pushing back because of concerns over code quality. It’s the age-old tension between product and engineering: shipping to meet market demands versus delivering with quality.
In today’s team meeting the debate escalated into an argument. It can happen so easily. Tom’s casual shrug of a shoulder or roll of the eyes, which Sue finds insulting; a few words from Sue that Tom sees as hostile. And we’re off – conflict ensues!
Our Reactions to Conflict are Instinctive
From the moment that critical comment is muttered or eyes rolled, our brains set into motion a series of instinctive, neurophysiological responses that are designed to warn us that danger is upon us.
We’ve all experienced it: our breath becomes more shallow, our hearts beat faster, our mouths get dry, our palms get sweaty, our legs and hands tremble. And while our bodies are going through their instinctive cycles, our emotions give us basically two choices: get angry and fight back or run. It’s fight or flight – reactions aligned to instinctive behaviours which have remained constant since early man.
How do Organisations Deal With Conflict? They Exploit or Avoid!
While we’re no longer living in caves, our reaction to conflict and danger has not evolved; we’ve simply adapted our reactions to our environment.
From my experiences, when it comes to dealing with conflict, organisations adopt one of two models:
Exploit – Organisations that “exploit” conflict, believe it is a secret sauce to building a great product or business. These organisations see conflict as the lifeblood of success, and as evidence that their employees care deeply about their work.
Avoid – On the other side of the spectrum are organisations that “avoid” conflict. They sweep tension and conflict under the rug. You can hear in the hallway whispers of “nothing to see here” as any issue or spark of conflict is put to the side and hopefully forgotten.
Far from ideal responses, these modeled approaches show how little progress has been made in dealing with conflict at work. And the financial ramifications of exploiting or avoiding are even more striking.
Conflict is Costly: Can you imagine all the things we could accomplish if we – and our organisations – had practices in place to manage conflict instead of exploiting or avoiding?
Conflict is not the “Secret Sauce” for a Great Product
As our opening scenario with Tom and Sue shows, product management has its own breed of conflict that is created naturally when you bring together core members of our traditional cross-functional teams: Engineering, Design and Product.
These functions have competing goals – technology strives for quality code and infrastructure, design strives for an optimal experience, and product looks to meet customer, market needs, and more. Sometimes competing, sometimes overlapping, these goals always create tension.
When I first started out in product management I was told that this tension was good, because through it we deliver a product that is the outcome of all three functions pushing each other to the limits.
I used to agree with that and just expect tension and conflict as part of the development process, but not any more.
Now I say that this great natural tension is a short-sighted condition that – in the vast majority of occasions – creates a legacy of financial and emotional waste. Conflict is not the secret sauce to delivering a great product.
You can do Something About Conflict: Build Your Product EQ
Here’s the deal. Conflict is not going away. There will always be tension at work. There is no magic spell or piece of advice I can give you that will make your workplace a haven of peace.
However, I believe that we as product managers are perfectly positioned to lead the change that our organisations need to move us away from Exploit and Avoid and toward an environment of productive conflict resolution.
How? By changing our own mental model about conflict, and realising that managing conflict is a skill that is essential to product management. Just like learning how to build a roadmap or do A/B testing, we can learn how to manage and de-escalate conflict.
The diagram at the start of this post depicts what I call Product EQ. It’s based on the concept from Daniel Goleman in his 1995 book, “Emotional Intelligence: Why it can matter more than IQ” and is updated with core competencies that I believe are essential to product management.
Goleman’s research explains that our predilection for tools and techniques like building roadmaps, A/B testing, or prioritisation is a result of the way our brains work.
The part of the brain that learns new technical skills – the neocortex – can learn quickly. However, the emotional brain doesn’t work as quickly – it can take months of focus and practice to improve EQ skills. But it can be done.
To be successful as a product manager, we all need tools and techniques that lay the basis of our craft, but even more importantly we need the EQ to deliver. After all, what are the chances of successfully building a complicated roadmap without the ability to resolve conflict, give and receive feedback, have organisational awareness and empathy?
Not Convinced? Take a Look at the Numbers
Why else should you care about building your Product EQ? There’s a correlation between strong EQ and bottom-line business performance. David MacClellen, a Harvard clinical psychologist, found that leaders with a high EQ outperformed annual revenue targets by as much as 20%. Conversely, those executives who lacked EQ rarely rated as outstanding in their annual reviews and their divisions underperformed by nearly as much.
Focus on Your Conflict Management Skills
The ability to de-escalate conflict and find a resolution is one of the skills that Goleman points to as a social skill and a crucial aspect of emotional intelligence. While the learned behaviour of conflict resolution will take time, let’s look at some more tactical ways you can start to be the change that your organisation needs.
How do you Deal With Conflict now?
Peter Drucker, pioneer in leadership and management, said: “You cannot manage other people unless you manage yourself first.” In other words, until you get to know yourself well, you won’t have the skills or competencies needed to lead and manage.
One way to understand your relationship with conflict now is through the Thomas-Kilmann Conflict Instrument – a tool designed to “measure a person’s behaviour in conflict situations.” Created in 1974 and taken by over eight million people to date, it’s now an online test that you and your team came take in about 15 minutes. The outcome will measure how you deal with conflict based on five different modes: competing, collaborating, compromising, avoiding or accommodating.
Build Conflict Resolution Into Your Team’s Ways of Working
Once you have a stronger sense of how you and your team deal with conflict, develop ways that you can build conflict resolution into your ways of working. For example:
Create a safe space for issues to be discussed and resolutions proposed. I’ve seen sessions called “beef hour,” or even weekly gatherings on Friday called “venting Friday”.It doesn’t matter what you call it, but the idea is to dedicate time to talk about tension in your team and come up with resolutions to resolve it (this is the most important part). This is not designed to be a “bitch session” or a “retro” but time to have open and honest conversation without finger pointing and an opportunity to decide as a team how to move forward.
Agree to basic principles of behaviour in times of conflict. For example members agree to act in good faith at all times – this means not spreading rumours and taking full responsibility for actions.
Training in a method of conflict resolution. The philosophy of Non-Violent Communication (aka Collaborative Communication) by Marshall Rosenberg is a popular option. Created in the 1960s from Rosenberg’s work with civil rights activists, Non-Violent Communication teaches four key components to help improve relationships and communications. The philosophy has been used to defuse gang fighting in New York, as part of the Middle East peace process, and in homes and offices across the world. Training is offered globally.
Ok, you’ve done some work on yourself and your own relationship with conflict, and your team has put in place ways to deal with conflict as part of ways of working. Now the conflict has happened. The next tips will help you deal with conflict in real time.
The timing for a conversation between the conflicting parties is delicate. Don’t bury your head in the sand and wait too long to talk through the tension, but at the same time don’t force the issue if people are tired and stressed. Be aware of when to have a conversation – make sure people have room to breathe and cool off, but don’t let that drag on for days.
Know Your Audience
If you’re in the midst of conflict, be mindful of your communication style. Consider the message you want to relay and what words and tone might have the best chance of actually getting received. Check out Dr Jody Foster’s book, “The Schmuck in My Office,” where she profiles the types of people we all find hard to work with and provides advice to build a better working relationship.
Consider the Details
Talk face-to-face – don’t send that email that you were up all night writing to the other person, telling them how angry and hurt you are. Don’t fight it out on Slack. Be a grown up, have a face-to-face conversation.
Go to a neutral place to talk – a coffee shop or location outside the office if possible.
Prioritise and start with the “easiest” challenge first – Unlike product development where we often start with the most challenging piece of functionality first, start easy here. If you can come to an agreement on a seemingly small issue you can build some confidence and trust to move on to the more challenging topics.
Equal time to talk – To help get your dialogue moving, try starting out by speaking in rounds. For example, agree to a certain amount of time for each person to talk about their grievances, say two minutes. Do as many rounds of two minutes as you need. The idea is to provide non-interrupted space to speak. Knowing that you won’t be interrupted can give you a liberating sense to get off your chest what you need and just talk.
Celebrate success – Being able to resolve conflict makes us feel more empowered and proactive. Acknowledging and celebrating that feeling goes a long way in furthering your practice to shifting your mental model about conflict.
Ask for help / mediation – Sometimes we need a bit of assistance in dealing with the conflict at hand – and that’s when it’s time to bring in a third party. It could be a manager, trusted coach or colleague whom you both feel comfortable with helping you work through the conflict.When acting as a mediator previously, I’ve tried the NVC approach from Rosenberg. He focuses on two questions: What do each of you need? and What would you like to ask of the other person relating to those needs?While these questions may seem easy, they actually push participants to identify where the tension is in direct conflict with their own needs, and what strategies those involved can agree to in hopes of preventing a repeat pattern. It may take a lot of time to get to the real need, but once you do, strategies tend to flow more easily.
The key is to Keep Learning
Conflict is not bad, but our inability to manage and resolve it is costing us dearly – financially and emotionally. With continued investment in personal development, and focus on building our Product EQ, we can build our conflict management skills and see the healthy outcomes that conflict can truly bring.
Summary: Build better product teams by hiring smart, diverse groups of people, getting out of the way, and focusing your teams on outcomes rather than outputs.
It’s not About Products, it’s About People
A lot of people think that product managers need to be experts in technology, user experience and business strategy. However, normally product managers have arrived in their role through just one of these areas of work – and are picking up the others as they go along. This is not a problem, because if you assemble your team in the right way, you can bring together all these skill sets and build great products.
Diversity Builds Better Products
Whether it’s ensuring your team is made up of people with different heritages, work experience or industry knowledge, the more diverse your team is, the better it will be at solving problems. Seek out complementary skill sets whenever you’re building a team or working with groups across an organisation. They will help you build empathy with your customer and with other stakeholders, which will in turn help you to build better products.
If you’re only using your engineers to code, you’re only
getting half their valueMarty Cagan
Product is a Team Sport
No matter what your role is in the team, the product is everyone’s responsibility. You may be a group of specialists, but real success depends on everyone contributing more than their own area of expertise. This is the point at which you get truly cross-functional teams that build products which are feasible while also solving the problems of your users.
Co-location for the win
By being in the same place as one another, you can have high bandwidth communication which helps you to solve the tricky problems that are the basis of your product. This is more important than having UX next to the customer and everyone else in the HQ – even though you should be going back and forth a lot.
Psychological Safety Produces the Best Teams
Those teams that feel they are safe to take risks and be vulnerable in front of one another, far outperform teams without this attribute. Such teams admit mistakes, are more likely to take on new challenges, generally harness new, diverse ideas and are happier to challenge the status quo – all hallmarks of awesome product teams.
Individuals’ Motivations Aren’t What you Expect
Rather than paying people more and more, or having generous bonus systems related to performance – we need to think about the conditions in which people operate to keep them motivated. The top three factors proposed by Daniel Pink which help individuals to perform their best work are:
Autonomy to make decisions and pursue what a person thinks is important
Mastery over a particular skill or craft
An understanding of the Purpose for what they are doing and why it’s important
Your Team is Smarter than you are
Product leaders need to build a way of operating, so that their teams can continue to deliver no matter what the scale of the organisation. By creating cross-functional, autonomous teams, decisions can be made nearer to the customer and they are more likely to be the right decisions. High-level guidance is still important. Leaders have a crucial role to play in defining how teams work together and in setting the vision – but the individual choices should be left to those best placed to make them. When done right, this results in a sweet-spot situation of high alignment and high autonomy.
Once you have got to the bottom of the problem you’re trying solve, your next steps are usually pretty obvious. If you know what the problem is, then you can easily articulate what success looks like and work backwards from there.
Pick the Approach that’s Right for Your Situation
The vast majority of modern delivery processes (agile, lean, waterfall etc) come from manufacturing processes. They are typically tuned to help you create solutions which are already defined, as quickly, efficiently and as error-free as possible. People who work in an environment in which the answer is not known tend to operate in a different way.
Be sure that you’re not trying to use optimised delivery methods for situations when you need to discover the right direction to take first. There are lots of ways to do this – discovery sprints, contextual research, dual-track agile, to name a few. Great product teams are able to adopt different modes for different problems, and work in a cycle which takes them from working out the right thing to build to building the thing right.
I recently read a write-up of what looked like a very interesting roundtable discussion with product leaders in London. The last of the four topics particularly caught my eye: “how do you increase the commercial acumen of product managers?”.
The article suggested that “product people (especially those in Europe) are weak commercially”, which “can lead to bad assumptions, particularly in more complex environments”. Two of the suggested solutions were to allow product managers to rotate through different departments around the business, or to always hire at least one product manager with an MBA or with more of a business than a tech background, and let the team learn from each other. Thinking about this challenge, I started to wonder whether the real problem is how we ensure that product managers are more well-rounded?
Which aspect the product manager is stronger in is often determined by their career prior to product management. If there is a perception that European product managers tend to be less commercially aware, perhaps this reflects the most common routes into product management? (though is this just speculation).
The question of how to help product managers to become more well-rounded made me reflect on my own career. When I first got into product management, I wasn’t particularly knowledgeable or experienced in any of the above disciplines so I really had to learn it all in one go. I didn’t have a Computer Science degree or an MBA and I didn’t have any experience with any part of the software development process. I held university degrees in linguistics and communications, I’d done lots of different jobs, ranging from admin to teaching, before and during my time at university and I was a second-year graduate trainee when I started a placement as a “product executive” (somewhere between an analyst and a product owner). I loved it from day one and soon realised this was what I should be doing. I started reading as much as I could to increase my understanding what it takes to be a good product manager.
Not long into that first job, the company hosted a hack day with the theme “give us an idea for a business we could invest in”. I was on the winning team that came up with Startup Startup, a platform aimed at connecting tech talent with early-stage startup ideas (you can find out what happened to Startup Startup here). Just six months into my product management career, after figuring out how to write and pitch a business case, I found myself in a startup office with a small, focused and cross-functional team, a small amount of funding and the challenge of turning our idea into an actual business.
Although I was lucky to have access to experienced mentors in and outside the company, it was still a sink-or-swim situation. I had to figure out how to apply all this Lean startup stuff I’d been reading about, how to manage my team’s P&L, work out if the idea could generate enough value to be sustainable, and build an MVP without running out of cash, while trying to keep up when the incredibly clever people on my team were explaining the choices we had to make from a tech point of view. It was an incredibly steep learning curve but probably the best thing that could have happened to me.
To frame this in a slightly different way, any cross-functional team needs to be well-rounded enough to cover the skills required to determine customer appetite, financial viability and technical feasibility when exploring new ideas or improvements. In the context of startup teams, this is sometimes described using archetypes like “Hacker”, “Hustler”, “Creative” and “Visionary” (this article explores this in more detail) but I would argue that most of it holds for any cross-functional team, regardless of what stage the business is at. The key here is that the archetypes don’t all have to be different people. Becoming more well-rounded could be defined as being able to wear more of the hats or take on more of the archetypes in a cross-functional team.
It’s Sink or Swim
Recruitment giant Indeed buys into the value of making its staff more well-rounded (stretching it beyond product management) and applying this at a more industrial scale. Indeed University is a 12-week programme that gives new hires the opportunity to come up with and test new ideas. Worst-case scenario, the new recruit joins the team they were hired to join with a better understanding of the business and of the process of testing and developing a new idea. Best-case scenario? They get to keep working on the idea they came up with.
As someone who really benefited from this kind of opportunity (and I like to think my employer got something out of it as well), I’m really pleased to see more organisations push employees in at the deep end. If we want to develop more commercially-minded product managers, more tech-savvy salespeople or more user-centric developers, presenting them with a chance to pursue an idea they believe in could be exactly what they need. It might be hard and it might not be for everyone, but when we encourage the right people to sink or swim I do believe we end up with more motivated and well-rounded teams and individuals.
What elements are required to make great product teams?
What are the key competencies needed to build a great product team?
Should product teams be based on longer term goals or short term feature needs?
How to balance accountability vs autonomy in product teams?
What are the typical growth areas for product managers?
The panellists stressed three areas to invest time on: defining goals, managing expectations, and executing with focus. In addition, it’s crucial to find a balance between the time spent with the product development teams and that spent in stakeholder management.
In terms of competency, Davide stressed the need for diversity – in all forms of the word – gender, culture and competency. Creating the right mix within a team ensures that all members have complementary skills sets and bond better as a group.
As for balancing accountability vs autonomy, Inge made an important point about empowering product teams. Goals should be clearly visible, and individuals need freedom and empowerment in order to work towards achieving these goals. Success largely depends on the motivation of individuals – if people in the team are results-oriented then magic will happen and clearly visible goals will be achieved. He illustrated this with a specific example of the OKR (Objectives and Key Results) leadership process.
Furthermore, Tom-Tom stressed that there is no one size that fits all. In smaller startups, founders have the autonomy to make product decisions quickly, based on their view of future direction. In larger organizations on the other hand, a lot of time is spent earning trust before gaining autonomy to drive product decisions.
In general, a great product team needs people with the ability to wear different hats at all times. Building product teams is all about creating an empowering environment for individuals to succeed, while giving people recognition for the achievements they bring to the table.
Summary: Done properly, applied artificial intelligence (AI) can enhance the user experience across your product – providing value for your users and your organisation. However, you need to allow your users to make the final judgement, spend time training your model, build in feedback loops and be transparent about how you’re using AI.
How to Apply AI
There are lots of different conversations going at the moment about artificial intelligence. Some are more abstract than others. The sharp end of research will continue to be out of product managers’ reach for a while yet – we’ll leave that to DeepMind. However there are numerous tools at our disposal to put AI to work now – and a few watch-outs for solving customer problems with these capabilities.
Start With the Problem, not the Solution
As all good product managers know, we need to identify the issues our users face and then find ways in which we can add value by solving them. It’s tempting to be led by the technology not the problems we’re trying to solve when working with new tools like AI. So avoid this mindset and be aware that not every problem can be solved with AI.
Any AI use Cases Have to Contribute to Your Overall Product Vision
It’s worth setting up some areas where you think AI can help to improve your product in order to investigate them. These areas must support your overall product vision – whether that’s making your users’ lives easier, removing hurdles within your product’s workflow and so on
Typical uses of AI at Diogo’s company, international media group Schibsted, have been to:
Auto-fill / suggest data for users
Identify steps that a user can skip
Help with non-intuitive tasks such as categorisation
Recognise real-world objects to save data input
The User is the Teacher and has the Final say
In any use case where you automatically suggest data to a user – such as categorisation of an item – you must allow them to “correct it” if they want to. You then must send this suggestion back to the AI tool so that it can keep learning and improving. You must track the number of these changes that users make, so you can measure the improvement of your feature. As it gets better, the feature becomes more effective and adds more value to your users and product.
Compare Human and AI Accuracies to Generate Buy-in
When implementing a new AI-powered feature, you need to test and monitor its accuracy. The best way to do this is to compare it against humans doing the same task. You may be surprised by how low the human success rates are for some tasks such as categorisation – and hence how good (or bad) your AI tool must be in order to still be worth investing in.
Don’t Forget Your Training Data
In order for your AI-powered feature to work, you need to train the algorithm on which it is based. This means you need data for the problem you’re trying to solve, with the correct answers attached. The more of this you have, the more accurate your model will be and the more value it will add to your product.
Decide how to Deal With Inaccuracy
Your AI won’t get the answer right every time. Fortunately though, it will give you a confidence metric with every suggestion. You can use this to decide what you want to show when it goes below a certain threshold. This can be a message to the user, allowing a choice or removing the feature altogether.
Be Transparent With Your Users
If you are using AI to change or influence the user experience, you have to let them know about it. If you don’t, they will get confused and stop trusting your product – causing issues across the board. Use copy like “auto-suggested XYZ” rather than just putting the information on a form.
For the past year, as Director of Training Products for Mind the Product, I’ve been creating a training platform and service. During this time I’ve worked with dozens of companies and hundreds of product managers; hearing about their challenges, and working with them to set game plans for shifting practices.
The one theme that has come out of working with these clients is that other departments in a company could work better with the product team/s. In my musings on how to address this issue, two tactics have emerged; the creation of understanding, and building a roadmap towards complementary practices.
So, how can departments who are not building software “mirror” the approach of product teams? By viewing their outputs as products, and taking the same approach to evaluation, communication and optimisation as best-practice product teams. Until my current job, my products were all software projects, so it was an eye-opener for me that, even though I’ve shifted to building a service model, nothing about the process I run has materially changed.
I’ve managed to shuffle the myriad of Mind the Product activities into four buckets in order to break down the process into pieces that other departments can mirror:
Align Around Goals
Product teams understand that in order to explore a complex and changeable domain, clear goals are a rock-solid requirement. This includes top-level goals that define a clear vision, but also more detailed goals that help teams to understand how they should measure their day-to-day outcomes.
I believe that once “testing goggles” have been acquired, they cannot be let go. Once a team understands that, each action they take is then a hypothesis, and outcomes either validate or invalidate what was understood about the product. At MTP this means that we structure all our activities as hypotheses, for example, “We bet that sending materials ahead of time will impact participant engagement,” and then we measure the results.
Take Stock Regularly
If a team is always testing and therefore always learning, then the distillation of what has been learned must be fed back into the product at regular intervals. For every major activity or milestone that MTP Training experiences, we have a retro with the team involved, evaluating what went well or what didn’t go well.
Bake in Continuous Improvement
Just reviewing the good and bad is not enough. Teams must also create and address activities that might cause improvements. Retros should culminate in a list of action items that are meant to alleviate past friction. An organisational culture of openness and transparency is needed in order to enable continuous improvement, but you can get started by scheduling retros consistently, and following through on the action items they surface.
I’ve seen bakeries and law firms espouse these concepts. In general, if an organisation can drive for general adoption of these processes, then not only will departments work more effectively with product teams, but they’ll generally work better.
For a few other articles on product-driven culture best practices, check out these blogs and talks from the MTP archive.
In many companies, improving engagement is a reactive process: as a product manager you wake up to a barrage of support requests after launching a new feature, or your in-app analytics reveal that new users are skipping over key functionality and never reaching their “aha!” moment. You shoulder the burden and – personally – work out a fix.
This approach is pretty common in B2B companies: in a world of high-touch sales cycles and complex products, getting hands-on with support requests and product problems used to be an important part of the product manager’s job description. But increasingly, many companies are taking the onus of product engagement away from the product manager and their support staff and giving it to the product itself. These “product-led” companies sell to other businesses but take their cues from companies like Facebook and Snapchat to create sales models, products, and user experiences that drive customers to use the product more.
This process starts with proactive onboarding: instead of waiting for new users to reach out and ask which features they should be using, you can use in-app cues to help them hit their goals before they ever have to ask.
This is hugely important for the first-run experience of any complex product. Product management tool Asana, for example, offers a wealth of functionality, from creating project milestones to building out visual reporting dashboards. But instead of overwhelming first-time users, simple tooltips offer a step-by-step tutorial, letting users learn the tool by getting hands-on with its core features.
Simple tooltips guide new users to Asana’s key features, straight from a user’s first in-app experience.
Even after a great onboarding experience, new users will always run into problems with a product. Instead of being reactive and waiting for the support inbox to fill up, you can take a proactive approach and build a product that is responsive to user problems as and when they emerge.
Another example of giving your product a voice: AdRoll uses a “pause interceptor”: a pop-up modal that triggers whenever a user hits pause on their campaign, offering them a timely opportunity to share their grievance. User responses are sent straight to the AdRoll customer support team, so the team can jump in and solve the users’ problems just minutes after they happen.
Run into a problem with AdRoll and a pop-up modal sends your complaint straight to the customer success team, without the need to file a support ticket.
Product knowledge bases play a similar role, allowing product and customer success teams to get their years of experience — strategies for best-using each feature, advice for integrating with other tools, examples of powerful use cases — out of their heads and into a searchable storehouse of product information.
Use Data to Refine Your Message
Just as you use verbal and non-verbal feedback when speaking to someone in real life, you can use user data to adjust your product’s voice and tone appropriately.
“You have to assimilate huge amounts of information—feedback from clients, quantitative data from your web analytics, research reports, market trends and statistics—you need to know everything about your market and your customer, and then mix all that information with a healthy dose of creativity to define a vision for your product.” –Martin Eriksson, Mind the Product
On the macro level, that starts with systematizing data analysis and creating a framework that anyone can use to identify and act on problems — like Fullstory’sflywheel of continuous improvement:
Identify problems using quantitative data, like low conversion rates, high bounce rates or rising churn.
Dig deeper with qualitative data, using surveys and phone calls to better understand the root cause.
Experiment with potential solutions, making small product changes to improve the customer experience.
In doing so, data analysis becomes a clear, objective process, no longer tied to any one person’s experience or opinion.
Create a clear, defined process for turning data into meaningful product improvements.
On the micro level, that means encouraging individual initiative and making it easy for anyone to uncover data and run experiments. Setting up shared access to data analytics tools can go a long way towards that goal, allowing other members of the product team to get hands-on with the analysis process.
In practice that might mean:
Making it easy to dig into in-app behavior with an analytics tool like Amplitude. What are people engaging with? What are they avoiding?
Use a data enrichment provider like Clearbit to reveal user information and personalize in-app experiences.
Remember, you don’t speak to your best friend the way you do a stranger on the street. Make sure you’re using all the information and behavioral cues from your users to have your product speak to them in the right way, too.
Make Product Management a Company-wide Pursuit
Many product teams are built from the top-down, designed primarily for the execution of a product manager’s ideas. In doing so, you’ve made yourself a bottleneck—no matter how creative or inspired your team, their ideas still have to be filtered through you, the manager. At best, iteration slows to a crawl. At worst, your team feels impotent.
Instead, you need to build a team of equals, where everyone is empowered to think about, and act on, product improvements. No team should be the sole source of inspiration.
“Great product managers not only tolerate, but actively enjoy the challenge of creating alignment and understanding between different roles and perspectives.” –Matt LeMay
Everyone in your company has a unique insight into the customer experience:
Marketing teams shape your customers’ on-site experience and share knowledge through educational resources.
Sales teams have a deep understanding of the questions and concerns shared by customers during the sales process.
Customer success teams manage the ongoing relationship and address customer problems as-and-when they occur.
Great companies are set up to feed learnings from each of these teams into the product development process, whether that’s in the form of a monthly all-hands meeting or by directly embedding marketing, sales, and support staff into the product management team.
Drift’s David Cancel dramatically shortened the feedback loop between customer support reps and product engineers by adding them to the same team.
These varied perspectives mean that the best onboarding experiences aren’t led solely by the product team: they’re a whole-company initiative, with every team playing an active part in the process.
Hack Conway’s Law
In 1967, computer programmer Melvin Conway said the “organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.”
By building a product with your whole company, your product will give back and support each of your teams, too. Your product might include a viral loop for the marketing team, or continually get feedback about users’ ongoing experiences for the customer success team, or possibly even alert the sales team when users look like they’re at the right moment for an upsell.
In doing so, you’ll build a product that can speak for yourself — or rather — it will speak for itself.
Summary: In order to drive lasting and sustainable change, you need to be curious about the people you’re working with and explore their perspectives. This helps you to collaborate with all parts of the organisation no matter what their attitude to change may be. Finally, you’ve got to be lean, delivering quick wins that you can build together to win hearts and minds.
Big Organisations Love the Idea of Innovation – but They Struggle With the Reality
Innovation is all about trying things, many of which which won’t work. It means prototyping, testing and learning; putting things into the real world which aren’t perfect. Whilst many big companies will say they want to experiment and fail fast – they invariably want to replace the word “fail”, with “succeed”. So, how do we operate in this context and still drive change?
Experimentation Feels Like Slow-Motion Failure
Many of your stakeholders may not be used to co-creating a solution that isn’t yet proven to work. They will likely have a particular skill – they understand that skill, have established ways of measuring its success and do not see the need for change. For them, discovery, making mistakes, and failing along the way is what they’ve spent their entire careers trying to avoid. Experimentation is a really significant shift in mindset. Work to understand this situation and how it makes people feel.
Digital is 10% Tech and 90% Human
Most organisations talk about digital transformation as if it is 90% tech and 10% human. They see it as a collection of tools developed to give them new capabilities. However, for these tools to function, you have to take account and develop the human side of things too. It is your role to focus on these changes just as much as the roadmaps of features you create.
Create Relationships and a Shared Vision
The relationships that you build will be your most powerful resource when trying to drive change with people who don’t see the need for it. You can use these relationships to connect with people on the purpose of why you are there. You will always find something to agree on, even if you disagree on some specifics. Do this, and you will be able to convince people to take risks and inch by inch, move forward.
Co-create Success Stories and Tell Them Again and Again
It’s tempting to hire a great group of specialists and for them to own the story of change at an organisation. In many ways, this allows you to achieve more in a shorter space of time. However it means you leave the organisation behind and ultimately it drags you backwards, and you fail to create lasting change. By genuinely incorporating the organisation into the process, you can ensure that people understand it, buy into it and will help to move it forward once you aren’t there. This will give the organisation stories of success that can be told by everybody in a way that others understand and helps to drive change sustainably.
Recruit a Team of Weebles – the Power is in the Recovery
Weebles wobble, but they never fall down. The knock-backs that you and your team will experience are the most important part of the process of change that you go through. Ensure your team understands this and doesn’t take it personally – but appreciates it as part of the change that they’re looking to drive. A relationship that’s broken down is a real opportunity for a new, stronger partnership. There is huge power in the recovery of a situation – that ultimately makes you stronger.
Tune in to What’s not Being Said and Explore it
You have a huge capacity to feel what is happening in any situation – even if it is not being said. We are able to perceive more than we can describe – use this skill to empathise with people when driving change. It’s often uncomfortable to discuss and explore these feelings – but it is a powerful way to drive progress. The best way to do this is find your biggest critic, sit down with them and work out what’s going on in their world to make them feel and act like they are.
It’s a useful exercise to sit down and work out where all your big influencers are on the grief curve. It allows you to engage with them in particular ways, depending on where they are. You’ll want to treat them differently depending on which stage they’re at. As always, build empathy with their feelings and work with them on a way out of it.
Look After Yourself
Change is hard for anyone. Driving change can feel like a never-ending battle that you’re always losing. Make sure that you have a community of support to help you work through this and deliver what you’re meant to for the organisation. If you’re not in a happy place, then you won’t be able to make the best choices for you, your team or your company. See this as a skill, that you have to practise in order to be an expert practitioner.
Mind the Product returns to Davies Symphony Hall in San Francisco on July 16-17 and promises to be one of our best product conferences yet, with a leadership forum, more workshops, more networking events around the conference, and more fun than ever before. As always the core of the conference is our line-up of amazing speakers, and the insights and stories they bring to the conference is what starts all those conversations. So I’m beyond excited to announce our first five speakers for #mtpcon SF:
The First Five Speakers
Christina Wodtke, Author and Lecturer
Christina has helped to grow companies like LinkedIn, Yahoo, Zynga, and the New York Times, as well as numerous startups throughout Silicon Valley. She’s the author of the business-fable book Radical Focus, a book which uses the power of story to build a new approach to OKRs, as well as the author of Information Architecture: Blueprints for the Web, Pencil Me In, and the upcoming Continuous Feedback. Christina currently teaches at Stanford on the HCI program in Computer Science. She speaks worldwide about humanity, teamwork, and the journey to excellence.
Leisa Reichelt, Head of Research and Insights at Atlassian
Leisa is responsible for building a better understanding of users and customers at Atlassian. Before that she built and led teams who transformed public services with user-centred service design at the Australian government and the UK Government’s Government Digital Service (GOV.UK). Before joining the public sector she was a freelance consultant and has worked with clients including Virgin Atlantic, BBC, SonyBMG, HSBC, The Economist, Drupal and the University of Surrey. Leisa tweets at @leisa and occasionally blogs at disambiguity.com.
Cindy Alvarez, Author and Principle Researcher at Microsoft
Cindy is the author of Lean Customer Development: How to Build Products Your Customers Will Buy. She is also a principal design researcher for Microsoft’s Cloud & Enterprise division, after spending over a decade leading interaction design, product management, and research for startups including Yodlee, Loomia, Kiss Metrics and Yammer.
Nir Eyal, Author and Investor
Nir founded two tech companies and has taught at the Stanford Graduate School of Business and the Hasso Plattner Institute of Design at Stanford. He is the author of the bestselling book Hooked: How to Build Habit-Forming Products. Nir is also an active investor in habit-forming technologies. Some of his past investments include: Refresh.io (acquired by LinkedIn), Worklife (acquired by Cisco), Eventbrite, Product Hunt, Marco Polo, Presence Learning, 7 Cups, Pana, Kahoot!, Byte Foods, Anchor.fm, and Symphony Commerce.
Dan Olsen, Author and Consultant
Dan wrote the bestseller The Lean Product Playbook and he works with CEOs and product leaders to help them build great products and strong product teams, often as interim VP of Product. Prior to consulting he worked at Intuit, where he led the Quicken product team to record sales and profit. He also led product management at social networking pioneer Friendster, and was the cofounder and CEO of YourVersion, a TechCrunch award-winning personalized news startup. Dan began his career designing nuclear-powered submarines.
Get your tickets
Don’t miss out on these amazing speakers and so much more, from side-events to networking and our epic after-party – get your tickets today!