How does the level of trust after a decision is made impact product teams (and other teams in your organization too)? How much waste might be happening in your organization because of cognitive biases and what are practical ways to avoid falling into the traps of these biases when it comes to decision making?
We explored these questions and many more with Adam Thomas, a product person and technologist based in Harlem, NY who is focused on strategy, team organization, and product management. Adam is currently the Lead Product Manager over at SmartRecruiters, a columnist at BuiltIn, and also shares weekly product management tips and other fun resources in his newsletter.
Adam believes that product management isn’t just about getting done what’s on the roadmap; it’s fundamentally about people. So he looks at things in a way that leverages behavioral science, psychology, philosophy, and more to build extraordinary teams that thoughtfully bake culture into what they are developing.
In this episode of the In Trust podcast, we talk to Adam about how he helps product teams get better results by putting people first. His practical perspectives and astute observations apply far beyond product management. Whether you’re a product person or a leader in a different domain, you’ll want to give this podcast a listen and take notes.
Overview of Episode 39: Helping Product Teams Get Better Results By Putting People First with Adam Thomas
Adam’s posture and philosophy as a technologist and product person
Why Adam rejects the box-checking, order-placing view of product management
Adam explains something he calls product calculus
Unpacking how trust comes into play specifically after decisions are made
Why there has to be a trust in failure
Why leaders can better serve their entire teams and their work by looking at work and culture through a lens of cultural anthropology
Adam’s practical tips for leaders to study the culture that they are immersed in
How sometimes one little push can change your entire organization
The high tax that bias plays in the workplace and how it is a silent killer of teams, processes, and development
The importance of conducting post-mortems on decision-making to understand how bias might have come into play
How regular pre-mortems can help minimize the bias tax
The importance of having a high cadence for company communications and how this can help bake in accountability into a workplace
The importance of talking about both successes and failures
How to reduce your chances of getting into trouble at work to nil
Starting small and building the muscle to take bigger and bigger risks
The basic thing you can do to have better meetings, more focused conversations, build trust, and other benefits
Where to learn more about Adam and read, watch, and listen to his work
Quotables
“I’d like to get completely away from that, let’s just call it determined roadmap. That preordained idea that we have some understanding as to what the future looks like, and instead move towards a place where we heighten our communication and we heighten our understanding of, not just the infrastructure of the company or sales requests, but also the people inside of that company, in order to live in that ambiguity – live in the space of just the unknown that exists inside of building things and making things. Be honest with ourselves around the concept of what I like to call product calculus, the fact that we’re never reaching something. It’s never a determined place that we’re reaching. We’re always approaching something.” – Adam Thomas
“I’ve seen companies create these huge plans, the leadership team is aligned, they have a big party, everybody goes, ‘This is awesome. We’re gonna really kill it over the next year.’ And then afterwards, six months or a year later, all the competitive advantages they had are gone and they have a product that no one uses no one cares about. A lot of that falls squarely on the product team because they didn’t have the trust inside of the organization post these decisions in order for other folks to trust them enough to carry them out. So I think decision trust is a huge, huge, huge piece of what product folks do.” – Adam Thomas
“There has to be a trust in failure, because I have never seen someone make something right the first time. No matter how much information I’ve sent back and gathered, I’ve never done it right. I could sit back for a year and gather information and talk to customers and do this and do that and I’ve never been right just saying, ‘this is what we’ve made. Ta-dah!’ So there has to be a level of comfort in the failure of what you do because the failure is coming. How folks trust your ability to deal with that and then to take that as a learning lesson, as opposed to playing the shame and blame game, really affects your ability to build stuff. Not just once, but consistently throughout your tenure as a product person.” – Adam Thomas
“As a leader, you should constantly be studying the culture that you’re in.” – Adam Thomas
“One thing to change the world: sometimes it’s just one little push and you can change your entire organization.” – Adam Thomas
“If I were to sit back and look at your operating expenses as a business, and I would suggest shadow your teams for three to six months, I could probably put a percentage on how much waste is happening based on bias. My bet for a lot of companies is that waste is upwards of 20 to 30%…With cognitive bias, since it’s so subtle, it’s such a silent killer of teams, processes, and development. It’s something that goes underneath the radar.” – Adam Thomas
“If you are communicating clearly, and you are being thoughtful, and I can tell that you’re showing your work, the chances of you getting in trouble are practically nil. You would have to do something extremely diabolical and in bad faith. I think most places work that way, especially once you understand what is the level of work that you need to show and who you need to communicate with.” – Adam Thomas
There’s a lot of uncertainty about the future, but one thing we are sure about is that The Future Is Trust. Which also happens to be the title of our forthcoming book.
The Future is Trust: Embracing the Era of Trust-Centered Leadership officially goes on sale on June 15, 2021
We are so excited to bring this reimagination of what a leadership book can be.
Projections are useful because they give the rest of the organization a concrete idea of what you’re working on. Unfortunately, they can also set unclear expectations and raise questions that go unanswered. But a better tool exists.
So, why do product managers (PdMs) plan as if we do when it comes to our strategy documents? In a previous article, I mentioned the trap that most roadmaps fall into. They give the rest of the company a time, date and feature. The plan usually ends up disappointing the business as a whole, though, as the date and time must often be moved, and after release, the feature doesn’t perform as promised.
The way to step out of this trap is to acknowledge the ambiguity of product management and tie the outputs, like that roadmap, to the outcomes you want. Turn the phrase “We will build feature X” into the goal, “We want to drive our customers to do Y.” When you do so, you train the business to give product development the flexibility it needs to solve problems instead of just delivering software.
PdM’s affect the decision fitness of a company. If we were simply keepers of the roadmap, the job would be simple enough. The thing is, we aren’t. And roadmaps aren’t the only place where PdM’s fall into this trap.
Let’s take it up a level. Managing strategy means we have to work on the way it’s communicated throughout the organization. Unfortunately, when product managers talk about strategy and explain where the business is going, we can fall into the same trap we do with roadmaps. We tell the company that we have a projection for the next few quarters. When we say this, we then watch the brows unfurrow, safe in the knowledge we get to live to fight another day.
So, this all sounds like a win, right? Well, projections are great until they aren’t. They’re susceptible to the same problems as feature-based roadmaps. You’re selling a one-way trip to the future, except you aren’t Doc Brown. It’s not a matter of if you’ll blow up, but when. And although one or two small explosions may not make people freak out, do it enough, and at best you’ll sideline the product team. At worst, you (and maybe your whole team) will be tightening up your resumes.
So, let’s talk about how to keep the positive aspects of a projection while giving yourself the flexibility to shift when you need to.
SCENARIO PLANNING
In product management, scenario planning is a way to address the shortcomings of simple projection. It presents multiple possible futures for a business and invites stakeholders to participate more fully in the product team’s strategy. Scenario planning involves making various assumptions about what the future will hold and how your environment will change over time. You lay out the scenarios that could happen, the risk/likelihood of each one happening and what factors can trigger them.
Remember that we have to respect the ambiguity of product management. I still haven’t found the person who was right on the first, well, anything: not on the first piece of research, software package or product roadmap. Any solutions that end up working long-term may have the right general idea upfront but usually require some iteration to be perfected.
The problem with using a projection is that it only gives you one shot to get things right. Much like a roadmap, as much as we tell ourselves that we’ll be able to make changes, once we put a projection out there, changing it is virtually impossible. What you say gets disseminated throughout the organization, and people play telephone. Once it’s out, you can’t put the genie back in the bottle.
So, why not just ditch projections altogether? Well, not having one is even worse: The rest of the organization doesn’t know what you’re thinking. If they can’t see anything coming from your team, there’s a slim chance that they’ll actually use your strategy.
If projections turn into traps, but we still need them, then what’s the best way forward? The answer is scenario planning.
Scenario planning involves making various assumptions about what the future will hold and how your environment will change over time. You lay out the scenarios that could happen, the risk/likelihood of each one happening and what factors can trigger them.
The Ups and Downs of Projections
Projections are popular because they give organizations a vision of the future that’s tangible, future-forward and trackable. Those are positive qualities that you’ll want to retain in your shift to scenario planning, so let’s take a look at what that entails and the associated problems.
TANGIBLE
Getting everyone in the company to read your strategy is a difficult task. As much work as you do to get people to engage with it, they often don’t. That means you need something concrete that will stick in people’s minds, even when the strategy document itself doesn’t land with the audience.
Projections are a great way to do just that because they give teams an easily summed up idea. It’s one point, and you can pop it on a slide and then go to sleep. Unfortunately, that simplicity is a trap. All it takes is a few slips of that projection, and people start to tune you out.
FUTURE-FORWARD
You need to show everyone that you’re looking to the future. Owning the decision fitness of the company is always forward-looking, even if we need to research the past heavily to get better at looking into the future.
When you make a projection, you tell a story that sheds light on a particular future, but it hides many things that build to that future. You end up unintentionally obscuring the risks.
TRACKABLE
How do you know what’s changing in the market, the customer base or even the company itself? Projections provide something you can go back to in order to get an idea of what has changed.
The problem is that you usually only get to pick one, and unless you pick well, you are hiding too much complexity. By showing only one metric or idea, you obscure the path it took to get there and increase the risk of outright failure. The right metric can lead people in the right direction, but unless you are an expert and know the domain and customer in an otherworldly fashion, you are going to get this wrong eventually.
Now, let’s make this real by looking at a projection-based organization versus a scenario-based one.
Projecting Into the Future
Let’s take a look at the company BobCo, looking to plan its second half of the year. The business is looking at product development and is focused on getting the outcome they need.
So, their head of product, Keith, decides to make a projection.
Before he creates the projection, he first does all the necessary leg work. He contacts different groups to get their perspectives, digs into the market intelligence and talks to the executive teams to get an idea of where they think the vision needs to go.
He sits down and, keeping his eye toward the future, makes a slide deck to show the company leaders at the next all-hands. The deck outlines the projections for the next quarter for product development, how they tie to the strategy and what that means for the future.
So, he goes through the slides and carefully details all the important factors in the projection. He includes the risks the team faces and the markers they need to hit to make their targets. With that said, he puts a single goal on the screen.
“We will reduce churn by 1.5 percent over the next two quarters.”
Everyone applauds, because they feel like they knew where they’re going now. The projection works.
Except.
Once the meeting is over and the leaders return to their individual teams, they only remember one thing: the churn rate. Everyone thinks, “Oh good, product is going to reduce the churn rate.” Nobody sees the role they have to play here. They see this metric as a promise rather than a goal.
To everyone in the meeting, the churn rate became tangible. But they didn’t remember the risks that were associated with making that goal. You see, that was just another slide on the way to the projection. As a result, the risks were obscured. Same thing with the larger story Keith told; it was just in service of that 1.5 percent metric. All the associated opportunities were lost as well.
Teams don’t know what they need to do, or even how to understand what keeps them off target. They can’t imagine any alternatives, or track any of the changes that might happen.
When teams aren’t aligned with the strategy, you’ll find that when they run into roadblocks, they’ll just guess about their next step. Those guesses vary wildly and can end up slowing down or, even worse, reversing progress.
So, while the team had some alignment around the ultimate target, by the time Q4 ended, they found themselves only a third of the way there. Everyone then wonders what they could have done differently and when.
Planning Scenarios
Let’s take a look at BobCo a year later. They’ve decided to scrap the projection approach because it didn’t work last year. They also didn’t understand why they weren’t able to communicate when things broke down.
The company needs flexibility. So, instead of projection, Keith chooses scenario planning.
Not surprisingly, the company has the same goal as before: to reduce churn.
Keith prepares the same way he did last year. He talks to everyone and gets their thoughts down. He includes the tangible anecdotes, the items that are future-forward and figures out how to track everything.
Where he changes his approach is in how he outlines the slides and the assets he produces. Before, the presentation built up entirely to the big finale: “Reduce churn by 1.5 percent.” This time, though, he wants to bake in flexibility by clearly tying the outcome to a set of conditionals. His slide now says the following:
“We’re going reduce churn by 1.5 percent by the end of Q4 IF”
The market trends continue as marketing predicts, letting us activate more customers.
Our engineering team has the freedom to leverage outside resources to build better.
HR consistently grows the headcount at the pace they’ve done for the last few quarters to continue a fresh influx of ideas.
The “IF” is important, as it invites people to be active participants in the plan instead of passive listeners. Now, their brains are moving. They can see that the goal isn’t guaranteed after all.
The job isn’t over, however. He goes on to add a bit more context to those three bullet points.
OPPORTUNITIES
The market trends continue to jump by 10 percent as marketing predicts, letting us activate more customers than last quarter by 15 percent to keep up with our place in the market, AND
Our engineering team has the freedom to leverage outside resources by bringing in a consulting team for less than 2 percent of potential profit to build better projects that will increase our upsells by 15 percent, AND
HR consistently grows the headcount at the pace they’ve done, maintaining our hiring targets at an 80 percent hit rate for the last few quarters to continue a fresh influx of ideas.
THEN we will reduce churn by 1.5 percent.
The AND establishes a story here. Whose roles are important? Well, the company now knows what product needs from marketing, engineering and HR. This is already more useful than just a statement about reducing churn.
These AND statements also set the stakes. If the company can’t do all three of these things, well, product isn’t going to hit the churn numbers.
So, what happens then? Keith’s presentation also lays that out:
“If we don’t hit our targets, we will”
If we run into issues in marketing, engineering or HR, and we can’t recover by week three of Q3, we will revise our churn number to 1.25 percent and adjust our internal messaging.
If it is past week three of Q3, and we revise the churn target, we will shift to our secondary target, increasing pricing to adjust for our loss. In this case, we will shift our teams and provide more support to marketing and pricing.
If we are failing with all three requirements, we will stop everything and reconvene to stop the bleeding. Our teams will be made aware, and we will call a town hall immediately.
With these statements, what was fuzzy before is now tangible, future-forward and trackable. Even better, Keith has added flexibility with the next step predetermined in each case to keep everyone moving forward.
At the end of the quarter, the team ended up shifting to pricing. They’re able to do a proper post mortem to find out that the churn target was too ambitious for several reasons. The next time they do scenario planning, they’ll be able to iterate and get even more precise.
Use Scenario Planning
Strategy is complicated and ever-changing. We need tools that can help us make the most of the time we have with our teams and equip them to do practical work.
Projections are tangible, future-forward and trackable, but they come loaded with risk. Derisk them by switching into a scenario planning model. Not only will you get the same benefits, but you’ll also train the organization to think about what-ifs and be more open to the ambiguity that comes with product management.
Because the world moves so fast, product management is seldom a linear process. We can’t afford to let our thought processes be linear, either. Welcome to product calculus.
Think back to your school days, and specifically math class. As you moved past arithmetic, you probably started your journey into advanced mathematics with algebra. As you built up your mathematical skills, you may have taken any of several different classes: geometry, advanced algebra, trigonometry, probability and statistics, and so on.
Often, a high school course of study in math culminates in calculus. That’s because, to master calculus, you need to have a solid foundation in all the other forms of advanced math. Calculus encompasses and builds on aspects of each of the other branches of math you’ve learned to that point. It challenges you to synthesize all your skills and take a step forward in your intellectual journey.
So, why am I talking about high school math? Well, it turns out that this provides a pretty good analogy for product management. When it comes to product management, some people are doing product algebra and others are doing product calculus. I’ve found that a lot of people in product think algebraically long after they should have progressed to calculus. So, let’s talk about how to avoid that and how to deepen your product thinking just like you did with your mathematical thinking.
WHAT IS PRODUCT CALCULUS?
Product calculus is a philosophy that embraces the fact that, as product managers, the ground is constantly shifting under our feet. Rather than settling for the easy answers and false certainty of a linear process, product calculus uses a mental model based on its namesake branch of mathematics to account for constant change.
Product Algebra
When I talk about algebra, I am focused on equations. Think about the equation 2x + 2 = 8. You can easily solve for x here because you’re looking for exactly one answer that fulfills the problem.
You can show the answer, and you can easily tell people how you got it. This entire process is a straight line. So, when I talk about product algebra, what I’m talking about is that straight line.
Product algebra boils down to how we, as product managers, can get straight answers to people. Now, if you’ve done product management, you automatically know that idea sounds weird because most of our work has nothing to do with straight answers.
How often do you get a chance to give someone a straight answer in your role as a product manager? Product management is contextual, which is why straight answers are hard to give with regard to how to do product, or even how to operate as a product manager. The ground is always moving underneath the PdM.
If you say you give straight answers all the time, then I’m going to guess that you aren’t actually doing product management. More likely, you’re doing product development delivery, helping things go from ideas to market. This is a serious role, but it’s more suited to project managers who have tools and processes that are designed to get teams aligned and ship products.
Product management isn’t here to help a team just ship software. In fact, sometimes, when a product manager is doing their job, no software gets shipped at all. Why? Product management’s main job is to heighten the decision fitness of an organization.
That doesn’t always mean shipping software. Your success shouldn’t be tied to how many lines of code flew out the door. Your job performance should be tied to how well your work empowers the organization to make smart decisions. This means helping to clarify strategy, which is always contextual.
Contextual factors include everything that can affect the work you’re doing. This might be the product itself, the customers and the marketplace, the internal environment of the company or even the politics of the U.S. as a whole. None of these factors are static. Anyone who has woken up to find alarms ringing thanks to a massive bug or a piece of legislation like General Data Protection Regulation can attest to how quickly things move in the world of product management.
This incredible pace of change means that strategy can’t be linear. You’re trying to synthesize all kinds of complex issues, and you’re trying to determine the probability that the next action is the best action. If all this were as simple as solving for x, then algebraic thinking would be fine. But again, if you can give straight answers, then you’ve probably found yourself doing delivery. I’d argue it’s not a great use of your time or talent as a PdM.
Product Calculus
So, if everything is contextual, how can we think about our work in mathematical terms?
If only there was a branch of math that focused on continuous change. Well, we’re in luck because there happens to be one devoted to just that: calculus.
Why is calculus relevant here? Well, since product management is primarily about improving the decision fitness of the folks involved in a product’s development, and all of those factors are constantly moving, then the job is a lot more like calculus than algebra.
Product managers are in the strategy business. Strategy isn’t about telling you where the puck is right now. It’s about telling you where it’s going.
The biggest mistake that product teams make when it comes to strategy is treating all the information they receive as if it’s static. That outlook leaves the decision fitness of the team dead in the water, and I’ll show you why.
Product Roadmaps and Product Management
When I see a team’s product roadmap, I can instantly tell if they’re stuck in algebra land.
Why talk about roadmaps here? For many folks outside of the discipline, the roadmap is where the rubber meets the road. It’s how people gauge the worth of a PdM since they’re often the most impactful document that they see come from the product manager. Look at any product management job description, and especially one written by a non-PdM, and “Make a roadmap” is often at the top of the list of tasks the PdM will be doing.
Most companies get roadmapping wrong, though, because they’re thinking about things in product algebra terms. Roadmaps are not themselves strategy. They are an output used to get folks aligned around the strategy. When a team isn’t careful, they can mistake the artifact, the roadmap, as the strategy itself.
When a team thinks this way, they can find themselves looking to solve an equation. That equation often looks like feature X + feature Y = market success. This almost never happens, though. More often than not, a company then goes back to the drawing board, just trying in vain to remake whatever the hot new startup is.
So it bears repeating: Roadmaps are not strategy. They are a communication tool designed to prepare a team to execute the strategy.
Let’s talk about two teams. One approaches their strategy with a product algebra lens, and another that practices product calculus.
Leadership gives the product team the following direction: They need to satisfy the market, improve customer relations and make investors happy.
The product leader, working with the product algebra lens, immediately thinks about the roadmap. They do a competitive analysis and look at feature requests from their most preferred customers. Soon, they have a roadmap, looking about a year in the future, ready to go.
They feel good about themselves, and leadership feels great about everything as well. After all, knowing where the market is going is a good thing, and they have some features that are ready to take the world by storm.
This is all well and good, except you can expect any and all of the following to happen:
Timelines Slipping: As a product person, you have more than likely seen timelines slip, oftentimes just by pure acts of God. All it takes is one bug, and that perfect map you’ve set up is out the window.
Backchanneling: As the timelines slip, teams often politicize decision making. Things are falling behind, so they need to rely on whoever they know “gets the job done.” As communication happens along multiple axes, more than one version of the truth begins to emerge. There’s the roadmap and the “roadmap.” Different teams make different decisions based on whether they’re in the in-group or whether they’re following the company messaging. When this happens, one thing is for sure: It will end up as a big mess.
Customers Changing: While this is happening in the background, your customers are continuing to ask for things. Sure, the customer had ideas about what they wanted three months ago, but I mean, that was three months ago, right? How long are they going to wait?
As these problems unfold, the team is still diligently working through the roadmap that the leader put together at the beginning of the year. The problem is that the product algebra mindset is linearly focused, looking to solve equations and get a single output. Nobody in this model has the capacity to handle changes to the plan.
Why do teams do things this way? Despite the obvious problems, algebraic thinking has one benefit: It provides false certainty. Making something, anything, fit an equation is so much easier than worrying about the rate of change.
Roadmaps are fragile communication documents that unfortunately often take on the characteristics of doctrine. The mistakes outlined above are only going to compound. Remember, context is always shifting. Some people will cling to the roadmap, given its doctrinal qualities, and others will ignore it altogether. Nobody will be aligned, nobody will have any way to adapt to changes, and things will only get worse as the context continues to evolve.
You can see how these issues really start affecting the long term health of your product team.
Let’s take a look at how the other team deals with the same circumstances.
Calculus Thrives on Change
Leadership gives the product team the following direction: They need to satisfy the market, improve customer relations and make investors happy.
This product leader sees the roadmap as a communication tool for the strategy. It’s a means to an end. Knowing that the ground is constantly shifting, that leader makes a strategy based on bets that are focused on outcomes.
These bets should have a few components. They need a question or a problem we’re trying to solve to give teams a place to start. That leader also makes some decisions that can help guide the team by laying out priorities. For example, the team might prefer quality over speed. There should also be a confidence level of completion to help teams gauge risk.
Following the instructions given by leadership, a product calculus roadmap could look like this:
The market is trending towards AI, and so let’s bet on automation. This bet means that question X (based on the situation) should have our focus due to problem A. We prioritize failure over building product this quarter. Due to our circumstances, we foresee this as an investment and have 35 percent confidence that we’ll end the quarter with a prototype.
Customer relations are disconnected, so let’s increase our investment in them. We’re looking to answer question Y, due to problem B. We prioritize building deep relationships with our current customers over generating new ones. Due to our circumstances, we have a great relationship with our customers and have 95 percent confidence that we’ll end the quarter with a prototype.
Investors are pushing us toward an IPO, and so let’s decrease our offering based on question Z, due to problem C. We will prioritize quality. We have 50 percent confidence that we will stay on track to IPO.
Why are these things important? In each bet, we’ve given those that read our strategy an understanding of our motives. The roadmap that follows can lead directly back to these bets and has the freedom to change when necessary. When teams look at the bets, they can make better decisions and move the product forward through shorter feedback loops that use those bets to get aligned.
For example, instead of just going through a sprint with goal to build a feature, as we would when doing product algebra, you can now check your work and metrics against those bets during your planning meetings instead of just trying to follow a timeline.
What does this approach do over the course of a year?
There is no timeline slippage since you aren’t making promises to the market. You’re only looking to solve problems. From those solutions, you’ve made the promise to look toward outcomes.
Teams are free from a timeline based on a magic feature. They can now decide to take on the problem on their own, eliminating the need to toggle between the roadmap and the “roadmap.” That ends any need for backchanneling since they own the bet. They can look for problems to solve and move forward at their own pace.
What if the customers request changes? Well, which bet do they fit under? If they aren’t critical or tied to the strategy by falling into one of those categories, feel free to ignore them for now. They aren’t important yet.
Since you are operating as if the ground is shifting and living inside of the ambiguity of reality, you can simply consider how fast it’s shifting and act based on that information.
Product calculus deals with that shifting ground by saying: “Hey, we don’t know exactly where we are, but we do know things will keep changing. Let’s adjust accordingly.”
There are plenty of concepts beyond just the roadmap that product owns to which you can apply this framework. If I had to leave you with something, though, it’s that being a product manager isn’t straightforward.
The best thing we can do is improve our decision fitness and use that to communicate clearly. That’s why a calculus mindset is so vital: It primes you to thrive in the real world where context is constantly shifting. When you’re doing product calculus, you’re less likely to be blindsided by anything because you’re always anticipating changes.
There’s a difference between privacy, which is based on trust, and secrecy, which isn’t. To maximize your team’s potential, you need to foster privacy and eschew secrecy.
Our mental spaces are fascinating. Sometimes, we may keep certain information to ourselves because we know that we’re trusted to complete a task. We don’t need to involve anyone else in our work. Other times, we may hold things back because we know that we aren’t trusted at all. Silence is a self-preservation strategy.
In both cases, though we did the exact same thing, the meaning was completely different because of the wider culture we were in.
This schism reflects the difference between privacy, which is based on trust, and secrecy, which isn’t. As a leader in whatever space you’re in, you need to understand whether you have created a privacy- or secrecy-based culture in order to understand the communication patterns inside of your organization.
Your communication culture has a huge impact on the rest of your business. Cultivating an atmosphere of trust is essential for success. The level of trust people in your organization place in leaders and one another affects productivity, the health of teammates and long-term employee retention.
You need to understand the difference between privacy and secrecy so that you’re not letting the latter shape your company’s culture. In fact, you may accidentally be pushing folks toward a secrecy-based communication pattern now. Fortunately, several tools exist for fixing this situation and getting your team feeling comfortable again.
Free Toolkit: Employee Retention Rate Calculator
Use our template to seamlessly calculate your own employee retention rate.
The differences between a privacy-based culture and a secrecy-based culture go deeper than the surface. Company culture affects everything it touches. To get a sense of how this works in practice, let’s look at a hypothetical product development team making a feature and how it might work in each culture to highlight the differences.
PRIVACY-BASED PRODUCT DEVELOPMENT
The cross-functional team confirms the plan for tackling their goals in the next quarter. They then set up a meeting cadence to check in, and they make clear communication rules in a public channel so the rest of the team can keep up with each other when there are questions. Backchanneling is nonexistent, and there aren’t many questions because micromanagement is at a minimum. The group identifies problems as they come up, brings them to the attention of everyone on the team and discusses them publicly.
SECRECY-BASED PRODUCT DEVELOPMENT
The cross-functional team confirms the plan for tackling their goals in the next quarter. The design team doesn’t trust the engineering team, so they don’t mention that they have a secret project to build a design system that will cut into the larger project. Engineering keeps their refactoring secret from product because they are tired of being “bothered.” Meetings are on the calendar to check in, but no one takes them seriously because all real communication goes through backchannels, and anything public, including the meetings, is just theater. Teams may identify problems, but they aren’t dealt with because no one believes they’re actually going to be solved. As a result, work slows down and management starts micromanaging to solve the issues. The micromanagement makes teams retreat more.
Unfortunately, from what I’ve seen, the latter scenario is closer to reality for a lot of teams. Let’s see some things that may lead to this kind of culture.
What Pushes Secrecy Culture?
Although many factors contribute to a secrecy culture, they all boil down to a lack of trust.
If I don’t believe that other members of my culture have my best interests at heart, I may decide to keep as many secrets as possible to prevent information from being leveraged against me. As human beings, our first instinct is to survive. This strategy makes sense as it’s kept our bloodlines around long enough to get to the present day.
Many of the behaviors in the secrecy-based example lead to a lack of trust. Let’s grab the two that I highlighted: backchanneling and micromanagement.
Backchanneling occurs when one person talks to someone else privately about strategy or execution.What makes backchanneling so insidious is that it starts off innocently. I think I’m just open a Slack DM between me and someone else to talk about something small. Unfortunately, it rarely stays that way. Soon that chat goes from a quick question to talking about the project, which then turns into making plans that exclude other people. Small things that you think no one notices can’t be kept under wraps for long though. People sense when they’re being left out, and, soon, folks get territorial.
Micromanagement involves someone in leadership looking to stay on top of everything someone is doing, no matter how minute. Micromanagement starts as a leader trying to help. Suddenly, what was once an attempt to pitch in undermines people and kills their confidence. Their productivity may experience a short boost before bottoming out. Other people close to those being micromanaged will also lose confidence because they worry that the manager is coming for them next.
Both backchanneling and micromanaging are easy to identify. When there are different answers to the same question, that’s the result of backchanneling. When you see clones instead of people, it’s a sign of micromanagement. The good news is that once you see these trends emerging in your team, there are some concrete steps you can take to roll them back.
Moving From Secrecy to Privacy
If you identify some of these behaviors in yourself or your team, don’t fall into the trap of saying, “We’re stopping this today!” If the culture is already damaged, you have a high probability of making things worse. Your decisive action will cause everyone to fall back into the same old habits. People will see the new plan as micromanagement and find their cliques to discuss what they think is really going on. Instead of taking drastic action, then, it’s worth taking time to do an investigation. Here are two tools to do just that.
RETROSPECTIVES
A retrospective is a way for a team to publicly talk about the issues that they’re facing. Teams are probably already aware of project retrospectives, but the useful type here is the variant called team retrospectives. These meetings are designed to give the team’s operational dynamics a postmortem. The first time you run one of these, you’ll notice surface problems, like teams having issues with each other, pop up. If you can, solve the simpler problems by making sure the right people talk to each other. Many issues can be handled with a conversation and a simple output, like “Next time we’ll talk with each other before we start work.” It’s important that once you get these things in motion, you ensure that the stuff you’ve discussed is actually happening. Follow-up is important for building trust. Eventually, you’ll see people bring up the deep-seated things that are making your culture secretive, and you’ll have a path to making it better.
ONE-ON-ONES
One-on-ones are a tool to help managers understand their teams by talking to the individual members privately. Both the manager and team members should use this time to talk about what’s going on in the company at large and how that person can improve in terms of individual contribution. Remember, managers micromanage because they think exercising complete control over everything and everyone works. We know that it doesn’t; good managers trust their teams to get things done and ask questions of team members to understand motivations. Being in a place where you can talk directly and frankly builds trust and helps to make things better.
Neither of these methods works overnight. What they will do, over time, is build stronger connections between management and the teams/team members themselves. As a leader, you’ll be able to see problems and get to the root of them. Remember, if your culture isn’t trustworthy, fixing it will take time.
Give People Privacy
As a manager, you must create an environment where people can feel like they own their privacy.
Tools like retrospectives and one-on-ones will go a long way toward building trust throughout the company. Getting away from backchannels and micromanagement will get you closer to an environment in which people feel confident and will handle any problems as a team.
Feeling better about where we work often leads to productivity gains and a better bottom line. Take advantage of that by starting with these tools today.
What if there were a way to figure out the problems that a project would encounter before you started work on it? With a premortem, you can do just that.
If there is one constant we can count on, it’s that mistakes will happen.
When we start a new project, though, that can be the furthest thing from our minds. We often approach a new challenge with a sense of optimism. Of course, we need to bring enthusiasm to our work. The downside is that we are then opening ourselves to being blindsided by problems we could have foreseen.
Over time, this can become a major problem. In the CI/CD world we live in, it’s never a question ofifwe’ll have new projects, but how many. As product managers, we own the decision fitness of a company, and the organizational debt that comes from those blindsidings adds up, ultimately affecting the company’s ability to reach its vision.
This responsibility becomes clearer when considering the questions that we tend to get and also the ones we ask ourselves. Often, these questions boil down to some version of “How do we know this will work?” We get so many variations of this question that a lot of PdM tooling is just figuring out how we can answer that one query in all its versions. Retrospectives are designed to help answer that question for past projects, but how can we ask it of future endeavors?
This question keeps product coaches and executives up at night, partially because there is no solution. If you knew the future, you wouldn’t need to be a product manager because you ought to just play roulette all day. For those of us without clairvoyance, though, the best we can do is minimize our risks and raise potential problems as soon as possible. After all, we know mistakes are unavoidable.
So, how do you do that?
Let me introduce the concept of the “premortem,” which is a workshop that can help identify problems before they happen. One of the outputs of organizational debt is fear, and this workshop helps shine a light on that fear so that teams can find alignment. I know this sounds a little scary, but as we walk through a premortem definition, how it creates an accurate map of an organization’s incentives, and how you can infuse it into your processes, you’ll see how you can use that fear to find holes in your own team’s alignment.
What Is a Premortem?
A premortem is a workshop that allows participants to give voice to their fears about potential sources of failure on a given project. It differs from its more well-known sibling, the postmortem, in that you do this before the project begins. The facilitator of the project asks the team to work backward from a hypothetical potential failure to understand how it happened and which behaviors you can avoid or adopt to dodge catastrophe.
What does bringing up problems before a project do for your team? It gets to a fundamental truth of organized structures: We often deal with the same issues over and over again. Bringing that fact up and making organizational fears and assumptions transparent to those around us is a great way to start to address the problem and end its grip on a team.
A premortem requires a facilitator, a note taker and representatives of the different teams that have some responsibility for the project’s success. The facilitator should ask and do all the following:
Based on a standard time horizon for a project in your organization, ask the group to brainstorm about some realistic ways this project could fail.
The facilitator should bundle these concepts together based on topic. In facilitator speak, this is called “affinitizing.”
The team can then prioritize the problems, first by talking about the groups, and then by voting on which topics are most important to the business.
Then the facilitator should ask the group to brainstorm again about how to avoid these potholes.
This process, which should take 60 to 90 minutes, will help teams clearly identify fears that they face that may currently be lurking under the surface. The meeting will help the teams to give voice to their anxieties and get everyone on the same page by specifically discussing the issues each group faces.
Why Is a Premortem Important?
So, let’s talk about potential failure, which is the foundation for this exercise. What if I asked you, “How will this imaginary project fail?” You might have trouble coming up with anything. In fact, it may seem very strange that anyone would even ask this question.
In practice, though, you’ll find that coming up with answers isn’t so hard. Let’s shift away from this article and imagine that you, as the product manager, are in a room with your team. You think about the last time a project failed and why. During this session, you recall that two teams didn’t interact well, which hampered the project.
In fact, you aren’t the only one who thinks this. Other people on your team do so as well. The facilitator asks, “What are some realistic ways this project could fail?” You all have plenty of things to say.
Next, you’ll work through why these things happened. As the team expands on the important failures, you’ll gather far more information on what happens when teams interact. The conversation will generate a great deal of insight into possible problems.
Finally, you’ll jump into solution mode and talk about what actions you can take to mitigate the risks you have mapped out. This is process improvement at its best, as you’ll be working with real problems and solutions tied to the fears of the team, based on the themes you’ve seen earlier.
Premortems Map Out an Organization’s Incentives
The process in the middle of the workshop, where we affinitize and come to an understanding of what the problems are, has a few components to it that will help you become a better product manager.
What makes the understanding section so powerful is that the person speaking will often share stories in which perceived slights took place. The stories you hear through the premortem will help you understand what fears folks in the organization are facing, both implicit and explicit. Sometimes, you’ll be lucky enough to hear the team articulate their fears in a fully formed way.
It’s a shortcut to understanding the politics of an organization. Politics aren’t quantifiable, so the information isn’t going to be as straightforward as a hard, quantified number. The qualitative anecdotes you hear, however, will help you identify how your organization works.
If you don’t understand the politics of the organization, you’ll soon wonder why various teams are apprehensive about certain tasks they’re given. This is where having a map, developed through a premortem, helps you to navigate problems.
Dealing With the Responses
You’ll notice two types of responses from the teams you speak with. They may talk about themselves, which we can call an internal assignment (i.e., self-awareness). Other times, they may talk about other teams, which we can call external assignment (i.e., blame). You should gauge the seriousness of each response by comparing them to the values of the company and asking the respondents to rank their importance on a scale of one to 10. Doing so will help you determine a course of action. Both internal and external assignments are worth investigating further.
Let’s look at a hypothetical example. Imagine that you’re talking with your marketing department as part of a premortem. You might get something like: “We got thrashed because our Q3 launch didn’t go well. We were just swamped.” This response would qualify as an internal assignment. It’s also pretty tame since it seems like a one-off issue.
Alternatively, sometimes the responses are very clear external assignments: “Our last release gave us way too many bugs because QA didn’t catch them, and they ruined it.” This is an external assignment and an alarm at that since the blame is absolute, especially if they use dramatic language like “ruined.”
As a product manager, this is where we put our detective hats on and hit the pavement, looking for the reasons why the incident happened. You are looking for sharp critique, blame, or the other failures teams talk about. Sometimes, you can find them in the postmortems of other projects or in written documentation in places like Confluence or notes buried in your company’s Google Drive. Try this with internal assignments.
Other times, the answers will be with the people in the org themselves, and it’s worth scheduling an informal follow-up chat to get more details. Conference rooms can work for something like this, but more often than not, getting some coffee or lunch will work even better. You want this conversation to be as casual as possible so that no one feels as if they’re under attack for placing blame. Remember, this is a fact-finding mission, not a blame game. This approach is particularly useful for external assignments since talking can clear up misunderstandings.
As a product person, it’s important to build relationships across the organization to find out where resources are and also identify hot button issues between teams. Premortems can help you accomplish this.
Making Premortems Real
Not all companies are created equal, and so you need to understand what ties the company together. This is where company culture and values come into play.
These concepts that you often see on the walls and on the website’s “About” page are the key to getting a premortem to happen within teams. Oftentimes, the values you see are at least implicitly agreed on, and since they are, you have the opportunity to use those principles as a shared framework to bridge the gap between groups. They are the lighthouse that can lead your team to safe harbor.
As you put the workshop together, make sure you refer to these values in the description. Do so both in writing as you send out communications and also when you get the team in the room. Since everyone agrees with these principles, at least in theory, people will be far more comfortable with the meeting. They should begin to see it less as a sniping session to get their political enemies and more as a way to get everyone on the same page.
Having a clear code of conduct helps to let people know that there are rules in place to maintain respect between people and teams. Everyone is looking to improve, so it matters how we talk to each other. Snark, sniping and backbiting are all counterproductive. Make sure that whoever facilitates lays out the ground rules and enforces tact in the conversation. Finally, this type of workshop requires clear communication and context. If you can’t get in a room together, video actually matters here.
Face Your Fears With a Premortem
Our first calls are almost never right. Same with our perspectives on the teams we are working with. The more alignment we have in the organization, and the higher our trust is inside of our teams, the better we are. We’ll need to have a map of where we are to be effective.
Premortems are a great tool to make that happen. By exploring the past before we engage with the present, we give ourselves a chance at a better future.
I’m going to share a harsh truth here. No, you don’t.
You need an architect, a project manager, or any number of jobs that directly speak to the problem you are facing. Your issue is that you haven’t defined that problem, and are more than likely listening to outside voices that “think” they know what product management is.
In my 13 years in tech, which I’ve spent building startups, consulting, and growing product teams, I’ve never, ever seen the use of a technical PM. My hope after you read this is that you’ll understand why, and as you build your product teams, avoid the trap this represents.
So, let’s start there — what does a technical PM represent?
“You know what we need? A technical PM.”
This is a prime example of what I like to call “conference babble:” listening to talks and workshops at a conference and mixing them all together with prior experience to create the world you want. “Technical PM” as a job description is conference babble of the highest order.
As product has taken another leap forward in consciousness as a discipline, plenty of folks have taken the stage and talked about their trials and tribulations. It’s part of the process. As product people, we are working out the nuances of what we do.
Experienced folks understand the nuance, while non-experienced folks may end up in conference babble land. And that is where the rise of “technical PMs” comes from. Why not take advantage of this increased nuance with “technical” skills, and we’ll have some kind of super engineer. Right?
Who doesn’t need that? With that thought in tow, folks come back and start typing job descriptions. “We’ll have a little bit of this, and a little bit of that, and they will be able to fill all these gaps. We’re unsure what we are asking for here, so let’s ask for everything.”
Another unfortunate second-order effect of product talking about what they have been able to accomplish is people getting the wrong idea of what product managers do.
In the eyes of some, they’ve become magic wands. If I wave a PM in that direction, then everything is fixed. They can “CEO” that function. So, why not throw “CTOing” that function in there as well?
That reminds me of what famed business author Seth Godin often speaks about, and what I’m calling the Cheesecake Factory dilemma.
Cheesecake Factory has a menu as thick as your doorknob. The food is mediocre because they cook everything — there is no focus or specialty.
There are no two ways about it; engineering and product are different disciplines. Both take years of experience to do well. By asking for someone to do both, it starts them down the path to mediocrity.
“Alright, we’ve found our technical PM. Now they can go solve the problem.”
Another tough truth: no, they can’t.
Let me hit the fast forward button on this since I’ve seen it a lot while consulting. Your engineering and product teams will have a cold war over this person. As a result, one of two things will probably happen.
They will turn into a project manager/architect by proxy with nagging commitments
They end up doing “PM” work anyway, title be damned.
No one hires senior technical PMs. There are no directors of technical product. This battle will play itself out, and that third-order culture effect could be devastating. If you are a person with hiring authority, part of your job is to minimize any cold war that can happen in an organization. Internal stressors are a company’s silent killer.
So let’s hit the rewind button.
“What is our problem?”
Hiring is a puzzle, no different from finding product-market fit, alpha, a bug, or whatever paradigm you subscribe to.
Eating at the Cheesecake Factory may mean you leave full, but the culinary experience won’t blow you away. Ask yourself: what are you really looking for?
If it’s someone to get projects running on time, go get a project manager. If it’s someone who understands the innards of a technical system, an architect will do well (plus, they are super technical).
Ask yourself what this person is for. Remember that being sincere about what you need can help your business grow.
“Wait, how will I know this what I need?”
Talk. Ask more questions.
Bring in outside counsel if you have to. There are plenty of product coaches that will help you settle what problem you are trying to solve and how doing so will improve your business.
The wrong hire won’t solve your problems — they will just exacerbate them. Worst-case scenario, you are starting a cold war between your product development teams that will slow down rather than speed up progress.
As product management becomes more popular as a discipline, the more trends — hiring and otherwise — will come and go. Remember that you don’t have to follow every one of them. Stay true to your organization’s needs and your product’s differentiators and you’ll avoid the “shiny new object” pitfall.
We work so hard to build a customer base that we despair at the thought of ever losing one. But sometimes, your relationship has run its course, and it’s smarter to let them go.
hen you build a product, you work so hard to attract those first customers. Cracking into a marketplace is difficult, and even when they have one foot in the door, it’s hard to keep them. Figuring out how to attract and retain customers consumes a huge amount of our time in the product world.
That being said, you also need to learn how to fire them.
I can already hear the objections: “Fire them? What about that hard work?”
Well, for your business to accomplish its mission, learning when and how to fire customers is a key skill. The truth is that both the business and its customers change over time. Sometimes, that change means that the partnership between the two has run its course. When this happens, you have a choice. Either you recognize the time has come and help that customer get to where they need to go, or you try to hold on, kicking and screaming.
Let’s eliminate the second option right now. Trying to keep your customers while they are kicking and screaming will leave scars. The effort, like blindly answering and accepting feature requests or requests for proposals (RFPs), to keep them is going to drain both you and your company. The cost is significant, causing companies to lose resources, headspace and may eventually move you away from your mission.
One day, you’ll look up and be unable to recognize your own company. If you’re a mission-focused company, then that type of change is non-negotiable. Keeping customers isn’t worth giving up on your original vision.
To avoid letting this happen, you have to be willing to fire customers. You need to do two things to fire them effectively:
Identify customers that don’t fit your point of view.
Send them on their way with some kindness and grace.
As leaders, and especially those of us who are mission-driven, we must be able to identify and part with those customers who no longer serve us well. Not only does doing so enable us to lead with razor focus, but it also helps signal to our colleagues that we are committed to the work itself.
In this article, I want to point out how you can identify customers who aren’t aligned with your mission. I will also address some ways to end the relationship without burning bridges permanently. Although some of these things are counterintuitive, they’re all designed to make sure that you, as a leader, are staying focused on what’s most important to your business.
Identify Customers That Don’t Fit
Earning that first dollar is challenging for a business, and keeping it is even harder. For founders especially, these dollars are an affirmation that your vision is viable, and every customer that you gain feels like a success.
Once you’ve got a sizable customer base, the job turns from just acquiring any customers to acquiring the right customer. I understand that the word right is doing a lot there, so let’s break it down.
The right customer is the one that fits your mission and vision. You solve a problem for them, so they’re willing to pay you for that solution. They’re excited to grow with you. These criteria may seem simple, but they don’t describe every customer that you have. Some are neutral, and some are actually the wrong customers.
Neutral customers aren’t enthusiastic supporters of your brand, but they’re comfortable enough with your service. They tend to slip in and out out of your revenue stream. They may eventually turn into the right customer and discover a passion for your product. Crucially, though, their indifference means that they don’t put pressure on you to change like wrong ones will.
Wrong customers want your company to do one of two things:
Go backward. The folks who push you in this direction are most likely older customers who joined when you first started. They liked your product in its early stages but don’t like what you’re doing now or where your product is headed. You’ll notice this customer talking about the old days a lot.
Change your mission. This group is likely to talk to you about everything except what your product is trying to do. Get ready for feature requests that overwhelm your team, tickets for your customer success operators that are far removed from your use cases and plenty of other distractions.
These groups are not mutually exclusive either. The person who wants to go backward can also push your team to go in another new, unnecessary direction too. Either way, the result is bad for your company. Going backward is as bad as spending time trying to accommodate every single request you see, no matter how small. Both strategies will put you out of the game.
Identifying these customers is important so that you can make your offloading process clear. Build a profile of a hypothetical problem customer so that you can identify red flag behaviors. Some things to look out for are improper or inactive feature use or a customer that complains often and contributes little to the bottom line.
You can set up user personae and include one for the problem customer. These personae, once uncovered, should be referenced with the customer experience team (customer success, customer support, support engineers, internal product and design) often to adjust and iterate as the mission changes.
Segmenting your customers will help you get a better handle on how to serve them all.
Helping People Move On
Now you have a good idea of how to identify those customers who don’t align with your vision. Once you’ve determined this, it’s critical that you transition them to someone who will provide a better fit. So, how do you help them move on?
Let’s start with what you shouldn’t do — just dump them. These customers, whether ideal or not, have shown you the respect of paying for your services or products. They put their faith in you, and even if they’re no longer a match for your business, dumping them either explicitly (by just cutting them off) or implicitly (by ignoring them) is a bad idea. Not only is it rude to treat someone this way, but you’re also running the risk of damaging your brand’s reputation.
So, what should you do? First, you need to understand them. Then, you shift those customers to their next place rather than unceremoniously dumping them.
UNDERSTANDING
Now that we know who these customers are, it’s worth understanding just how the relationship got to this place. This is counterintuitive because we’re often just focused on engaging with the customers that are the best fit for our product. Nevertheless, we can learn a lot from a disaffected customer.
There is more than likely messaging on your platform or marketing that speaks to the customers that didn’t fit. Asking these customers questions over the phone or by survey like “What confused or frustrated you?” will give you a hint as to what made them think that your product solved their problem. You now know what to remove in order to avoid attracting this type of customer. The data you get from the customer, whether from surveys or phone calls, will also give you some insight into the next step.
SHIFTING
The customers have told you what they’re looking for. Now, it’s part of your job to find out where to direct them. There are competitors (yes — your competitors) that may fit their needs better. You may also be able to recommend a solution that won’t charge them. Moving those customers to other places in your niche has two effects.
First, it strengthens your standing in the marketplace by focusing on just the customers that work for you and your business. Second, you can start to divert them before and during the onboarding process to avoid the trouble these customers can cause down the road.
Not all customers are for you, but that doesn’t mean you should abandon them altogether. Pointing customers who no longer fit your brand to a competitor who might makes you a leader in your space and improves your influence, strengthening the overall ecosystem. Don’t downplay the long-term benefits of doing so, either. Your competitor can become your greatest partner as the seas change.
The same goes for moving the customer off of your platform to something free. You’re building trust with that customer that may pay off big time in the future. Even as they’re leaving your service, they’re likely to remain an evangelist for your brand. Plus, getting these customers out of your pipeline frees space for the ones you need to pay attention to.
Fire Customers With Respect
These aren’t one-time actions. Identifying and moving those customers should be a continuous process. Every time you make space for the right customers, you are on the path to growth.
I know it’s hard, as the customers who started with us or the ones we’ve gained along the way are important to us. They trusted us. That being said, it’s worth returning the favor by helping them continue on their journey.
Too many times I’ve heard this: “I know what the customer wants.”
Immediately, my brow furrows a bit, as I press for more answers. Usually, at this point, I ask, “How do you know?”
What happens next tells you a good deal about the maturity of the product development practice you’re dealing with. Unfortunately, for most folks, the answer here is the wrong one.
In my 13 years in technology, I’ve heard the wrong answer over and over again. It’s usually some form of “We just know.” You can translate that answer into the truth, which is that the team has an ego problem.
When teams tell me this, I often imagine a tape playing in their heads that sounds something like this: “That’s why I was hired/founded the company. I’m here because I know what the customer wants. Why else would I be here as a [insert role here]? I’m here because I have a good feel for what the customer wants.”
Sorry to break it to you — whatever you do, that isn’t what you’re here for. You’re not an intuition machine with infallible judgment. The goal of any company is to use the tools and people it has to make great products that drive profits. That’s how you win customers, and it’s how you’ll keep them.
Unfortunately, plenty of teams don’t take this tack. They believe everyone is there because of what they, and they alone, innately know. This attitude is extremely limiting to the work we need to do as product managers.
I firmly believe that one cannot think and know at the same time. Once you’ve decided you know something, you’re shutting yourself off to engaging with the topic further. When it comes to product development, though, there is no way to truly know things. Not even a team doing all the research it could possibly do knows the right answer. It doesn’t exist. When you say “I know,” you’re just closing the door on a whole host of possibilities.
There are just too many options and complexities for a right answer to exist. Think of product management like calculus: There are many possible answers, not just one. If you’re focused on knowing a so-called right answer, you aren’t doing any type of user-centered development.
Instead, you’re engaging in ego-driven development. This leads teams to waste a lot of time building things the customer doesn’t need, leaving the customer unsatisfied and the company with a bunch of undue overhead from products they don’t need to carry. Worse, you’re hampering your team’s ability to do great work. The best product development teams focus on learning. If you aren’t thinking about the customer, then you’re robbing your team from doing just that.
Well, like all things, the road to hell is paved with good intentions. Here, the problem begins with taste. Taste is your innate sense about whether or not something works. The one thing about product management that you can’t teach is taste.
Before we go any further, I think it’s worth taking a moment to say that taste is what got you into whatever you’re doing. It’s an important piece of the puzzle. As a beginner, it’s all you have. As you gather more experience, you begin to close the gap between your taste and your ability to create new things. Ira Glass makes a good point on this subject.
Your current job, your next job and your ultimate legacy in this business are all built on that taste. It’s the thing that makes things happen. And that’s good. You need to have taste!
So, clearly, taste is important. When it goes too far, though, you start to enter ego territory. We can’t afford to have our taste become a dictator. That’s when bias takes over and blinds us to better outcomes. When we do that, we’re not thinking about the user, but ourselves. That’s when we’re practicing ego-driven development.
Identifying Ego-Driven Development
So, now that we have a definition, how do you know when your team is operating from an ego-driven place?
In the introduction to this piece, I highlighted the difference between thinking and knowing. That’s where teams go wrong. They move their discussions from “thinking about the customer” to “knowing the customer.”
This can manifest itself in different ways:
A lack of customer connection.
Building fast and learning slow.
Missing opportunities to reflect.
Let’s examine each of these issues and some ways to solve them.
A LACK OF CUSTOMER CONNECTION
When was the last time you talked to a customer?
I don’t mean talked at them to sell something, either; I mean to them. What are their hopes, dreams and the problems they’re facing? How does your customer intend to get closer to the hopes and dreams and away from the problems? Are they willing to invest? Are they ready to leave?
All of these questions are important to ask and give you guidance on how to think about the customer. When you talk to the customer regularly, you begin to mix your taste with an overall sense of their problems. That is where product development becomes powerful.
BUILDING FAST AND LEARNING SLOW
Is your team’s mindset always focused on pushing ahead to the next sprint?
Whoa, there! What was the last thing we learned about the customer who’s using this product of ours? In fact, did it solve their problem? Is this worth continuing? Are we missing something in the market? What about our competitors?
If you are just building, and not investigating, not only are you missing out on getting to know the space your product holds, but you’re also underinformed about the marketplace as a whole.
The marketplace is constantly changing. So, if you aren’t building on your knowledge every time, your team begins to rely on luck. This means you can’t consistently ship good projects. You might get lucky once or twice, but you’ll eventually strike out.
MISSING OPPORTUNITIES TO REFLECT
How are we working right now?
It’s vital that we look at what we are making, but it’s just as important to understand how we’re working together as a team. How is our team morale? Are we overworked? Are we bored? Are we stuck in a rut?
If you aren’t investigating yourself, how can you get better as a unit?
Your taste needs to get better too. If you can’t find alignment with the other people on your team, the distance between you, them, and the project grows, ultimately hampering your ability to ship good products.
Avoid Ego and Improve Your Products
Business is constantly evolving. Our customers are changing, and the problems around us are growing more complex. This requires getting out of our heads and paying attention. Ego-driven development isn’t going to help us keep up with the pace of change. Although an ego-driven process may make us feel better in the short term, it has disastrous long-term implications, up to and including kicking us out of the marketplace altogether.
That’s why it’s so important to check in on all of these factors. Doing so allows us to take our ego out of the equation and make good decisions.
Make things that matter. I can’t think of better work than that.
So, you’ve made the hire. Congratulations — finding the right product manager who can help your team succeed is a huge burden off your shoulders. As a member of the welcoming committee, you well know that onboarding is extremely important to the success of your new colleague.
A bad onboarding process is essentially running that brand-new hire you just made out the door — and a sizable number will leave before they can do anything they promised during the interview process. Onboarding new employees isn’t something that should be taken lightly.
Except that it is.
In fact, Gallup puts the percentage of companies doing poor onboarding at a whopping 88%. That means that you aren’t seeing things — yes, people are leaving jobs rapidly. And while much of that can be blamed on bad management, the specter of bad onboarding can be just as impactful.
Onboarding in product management
Those are generalizations about the overall workforce, and while I don’t have a ton of peer backed numbers, I can be fairly confident that the trends follow in the discipline of product management. My conversations with product leaders and founders tend to support that notion, as one of their struggles continues to be keeping great talent. They find that new hires don’t quite find their footing and seem to never reach full productivity. Those folks tend to start looking elsewhere.
All of that work to bring in someone for them to leave in a few quarters is devastating.
This article is going to address the difficulties that product managers face during the onboarding process. These challenges are based on the understanding that product managers are there to help facilitate product decision-making within an organization. This means that the first few months of a product manager’s tenure is more akin to being a “detective” than anything else.
How a company prepares a PM during the onboarding process can be the difference between a long-lasting team member and a flash-in-the-pan who sends you right back to the hiring boards.
The challenges are that product managers have to:
Figure out the company’s place in the market from scratch
Understand past decisions
Know what their areas of responsibilities are and what power they wield
Let’s go through each of these in turn. I’ll share a few things you can do to move your new hire along so they can be effective, plus some things to throw into the welcome pack to help them on their way.
Figure out the company’s place in the market from scratch
Your company doesn’t exist in a vacuum. Even if you are creating something on the edges, there is often an alternative that your customer base is currently using to solve their problem(s).
When a new product manager comes on board, it’s critical that they get this information as early as possible. This allows them to ask questions that can improve the current “map” of the company. After all, you hired them for a reason! When armed with accurate knowledge of the market, a product manager is more confident in the bets they make and less likely to run afoul of silent rules that exist in the marketplace.
Put these in the welcome pack: A list of current competitors, the rules of the market from leadership’s point of view, and your business strategy, along with all the artifacts that accompany it.
Understand past decisions
The company doesn’t exist in a vacuum, either externally or internally. The team or organization made a number of critical decisions in the past, and the company learned from them.
When your new product manager comes on board, they need to know what those decisions were, who made them, and what the company discovered. As they learn this, they get a picture of where they can add value based on their experience and what they don’t need to re-learn. This means they can use their energy effectively going forward. This also applies to the things people in leadership positions won’t do. There’s no need for the new hire to waste their efforts.
Put these in the welcome pack: The last six months of major decisions, an org chart, product mission/vision/strategy, and a list of anything that the company won’t do.
Know what their areas of responsibilities are and what power they wield
Building on the idea of “wasting energy,” it’s very easy to do so in a new organization, especially as a product manager. When you don’t know what you can do without getting the “ok,” it can be frustrating. It hints at dysfunction within leadership because when these things aren’t clear, people don’t act.
When your new product manager comes on board, they need to know what they can do. Can they just run a research study without an “OK?” Is it company policy for them to be able to hop on a plane to see customers without your sign-off? How about changing the roadmap? What about bringing in new software? If you are thrown off by these questions, I’ve got more, and they easily compound. Don’t waste your new hire’s time — let them know what they can do without asking permission.
Put these in the welcome pack: Rules on company spending/training spending/research spending, old research wins and losses, and anecdotes on when the company changed course.
Time is of the essence
You’ve made the hire. The person is coming in the door. They are smart and accomplished and are ready to help make the business better.
You trusted them enough with the offer, so help them out, and get them onboarded so they can get right to work, the right way.
Product operations (product ops), the product management discipline’s latest way to track and understand the inputs that drive product strategy, is important. Far too long companies have had it “easy” in product development accounting, as projects were often “done” when they were shipped, and the numbers were rarely investigated more than superficially after that point.
Work from Melissa Perri (CEO at Produx Labs) and Christine Itwaru (Director of Product Operations at Pendo) in the public sphere, as well as some of the work here at Mind the Product, highlight the importance of product operations. To the uninitiated, product ops represents a systematic way to connect your data and processes to product development outcomes. If you’ve ever wondered what product development “costs”, and tried to model it in a way that helps you forecast, product ops is your skill.
As a coach for product development leaders at Approaching One, I often chat with leaders about product ops, especially at smaller companies. A very common topic is how they can engage with systematic product ops practices, and use them to make better product decisions with less waste. Of course, this is after the company has committed to embracing product operations. If your organisation isn’t there yet, I recommend looking at Melissa and Christine’s work (linked above) and advocating for it, if you’re encountering that kind of systematic “leakage” in your data and processes.
Over the course of my conversations with leaders, I’ve noticed a few common product ops pitfalls:
A lack of data fluency
No insight into learning opportunities
Failing to think about innovation
These pitfalls leave teams not getting the most out of the product ops they’ve set up – which is doubly frustrating for them because the most common goal of starting to deploy product ops is to gain efficiencies! I want to talk about all three, and ways you can immediately use the data you are collecting to get more out of the product operations work that you are already doing.
1. Lack of Data Fluency
Many of the tools we use make sure they can import and export data. It’s overwhelming, because suddenly data exists in multiple forms, in multiple tools, for various purposes.
The key issue I hear about from product leaders isn’t a lack of data, it’s a lack of alignment around that data. To gain organisational alignment, the organisation must have a level of data fluency.
What is Data Fluency?
Data fluency is the ability to understand the data that you collect, and being able to apply it to something meaningful. It isn’t how much data you have, but how effectively you can use it.
As a product leader, you’ll need to be able to judge your team’s ability to understand the data you’re using to achieve business goals. Ask yourself this question:
If I randomly asked someone in the organisation to tell me what the most important KPI is, where they get the data from and why… could they answer it meaningfully?
For most teams, the answer is a slightly sheepish “No”. This is a sign that, even though you are collecting good data, there is an opportunity to evangelise better practices and alignment. For product ops to be useful across the organisation, you’ll need to make sure that people understand why the data is important, what are the critical sources of data, and of course – what the key metric is.
If there is a lack of understanding, well, that’s a great lead-in to our next section…
2. No Insight Into Learning Opportunities
Great product teams aren’t judged just by their ability to create things, but also to learn. The more a product team learns in service to a company’s mission, and uses those learnings to create impact while minimising risk, the better the company’s “decision fitness” tends to be.
Learning doesn’t just come with a launch. Every interaction with a customer can lead to learning that improves the decision fitness of the entire company. More importantly, when you have solid product operations going, the data you collect should give you insight on how learning is going across the company, as well as the gaps in the company’s knowledge.
It’s worth asking yourself this question:
If I asked people what was the last major learning we had as a company – would people have similar answers?
If teams are unsure when and where learning opportunities are coming from, then any progress you make on “insights” is random, at best. The point of product ops is to tie numbers to outcomes to improve those numbers, and create a consistent cadence of learning opportunities.
Speaking of improvement…
3. Failing To Think About Innovation
How is your research and development (R&D) going?
If you are wondering if you have R&D, you do – if you are a young startup, then your entire existence is R&D. If you are a larger company, you still have R&D – and if you aren’t intentionally managing it, then it’s happening in pockets, organically.
In these ad-hoc situations, this turns into “science experiments”, or projects that come from the bottom up. You’ve probably got a rogue executive with interesting, creative ideas, who may or may not be in line with the vision of the product.
This might sound like a great idea initially, however, too many uncoordinated science experiments in a company dooms it to being a hamster wheel. If you ever wondered why your team seems to be in the same place despite constantly trying out ideas and experiments – well, I’d bet that you are in the middle of an uncoordinated treadmill.
Ask Yourself Again – how is Your R&D Going?
Innovation can happen randomly and organically. However, if you want it to happen consistently, you need some process. If you find yourself in a place where you feel things are the same, like an innovation treadmill, it’s worth investigating that process as a whole.
Product ops is designed to give you a place to start your investigation. What’s new? What’s different? Where are we gathering information? Is that information useful? How impactful was our last experiment?
Those questions (among others) will help you understand if you are on that innovation treadmill, or if organisational creativity is a random, chaotic process. If you find yourself there, asking those questions and making changes to either stabilise or energise can bring some consistency into your innovation process.
You’ll find some great opportunities through your product operations data.
Conclusion
Product operations are important. The data we collect there can lead to massive insights that scale and build across the entire organisation. Having it available and consistent is a huge plus when it comes to finding alignment, and making things happen at high velocity
That’s why it’s critical to make sure you are keeping an eye on your company’s data fluency, its learning cadence, and its R&D coordination to ensure you’re using your resources to effectively get product operations up and running, and to massively level up your product organisation.
There’s more where that came from! Access more insights on product ops
roduct managers (PdM) don’t make anything. Well, at least they don’t in the traditional sense. When it comes to product development, the product manager, unless under duress due to a lack of resources, bad planning, or maybe both, isn’t writing production code or crafting customer interactions. What they are doing at their best, though, is managing the decision science of the team.
PdMs spend their time making decisions that affect how the team decides … well, anything. They are busy prioritizing the needs of product development, managing the velocity of the decisions that the team is facing, or working on any number of projects that shape how the team makes decisions.
Today, I’d like for us to take a trip with cognitive science and talk about two concepts: availability bias and recency bias. Whether you realize it or not, you’re susceptible to both of these biases. In fact, they can even shift how product teams operate. The good news is that you, as a product manager, can actually leverage them to improve your team’s decision making.
THE BIASES
Recency bias is exactly what its name implies: A bias that privileges things that have recently happened. Have you ever sat in a meeting and noticed that decisions seem to largely get made at the end of the meeting, and the players inside of that meeting only reference data from the last 15 minutes? If so, you, my friend, have seen recency bias in action.
Availability bias is similar to its recency counterpart in that it privileges data based on ease of access rather than quality. It involves making decisions using whatever information is immediately available. You’ve also probably seen this one in practice as well. If you’ve ever been in a meeting and watched people choose the first idea that comes to mind, that’s it. Its main difference from recency is that availability bias isn’t time-locked. Someone may have research they rely on that they’ve collected months or even years ago.
As product people, one of our roles in an organization is to improve the decision-making process for product development. Both of these biases affect our output, which we can think of as the company’s “decision fitness,” or how well we make the decisions that affect our outcomes. Without managing these biases, you’re lowering the fitness of the company and are on a sure road to shallow decision making. So let’s ask how well we’re making decisions.
WHERE DOES PRODUCT MANAGEMENT COME INTO PLAY?
Since we product managers don’t have any tangible output, upgrading everyone’s ability to make decisions is a way for us to show our value and also functions as a metric for us to gauge ourselves. Our battlefield is often the research lab. For product managers, this isn’t the stereotypical science lab that comes to mind, but rather the place where we do research and one-on-ones with other stakeholders. We also ply our trade in the meeting room, and, in both spaces, we need to be vigilant in watching for the following red flags from our teams.
On recency bias:
Meetings without any agenda or facilitation. If no one is managing the conversation, our brains will default to the last thing we heard.
The roadmap is just the highest-paid person’s opinion (HiPPO). The tactics you use to get to the outcomes you want should have a variety of sources. If you only have one source, you have a problem.
On availability bias:
Quick decisions and buzzer logic. We’ve spent all the time in the meeting talking about potential strategies only to take the first one available.
Teams not using research. Research always has curveballs. For example, it might show that your customers are using features to solve unforeseen problems and maybe causing new ones. If the decisions you come to haven’t considered even the possibility of alternatives, you’ll have shallow outcomes.
SO WE CAN IDENTIFY BIAS. NOW WHAT?
Now that we know how to spot bias, let’s leverage it. We can’t change how the human brain works. Trust me, I’ve tried. You aren’t going to get rid of cognitive bias — but if you have, please, email me!. What we can do instead is put processes in place that understand these biases exists and use them to help our decision making.
So, let’s talk tactics.
Strive for short decision-making cycles. Ask yourself, “How can I make the decision-making cycle in a meeting as small as possible?” Far too often, teams wait until the end of meetings to make decisions. That timing falls into the traps we saw earlier. This likely means structuring meetings in decision cycles instead of theme, which brings us to our next tactic.
Meeting discipline. We all hate meetings, and I get that. Despite their unpopularity, they’re a useful tool for finding alignment and making decisions. PdMs should own meeting management for product development and ensure that people walk into meetings with context. Those cycles should leverage availability bias by making the right artifacts available at the right time and recency bias by making decisions in each cycle instead of waiting until the end of the meeting. That way, you’re structuring the meeting to take advantage of the bias instead of letting it derail your process.
Research discipline. Much like meetings, your participants, whether they are internal or external, will fall into the trap of biased thinking. Make sure you have a few good questions and set the table for those who want to understand the research can access the information. If the team trusts the research, and it’s available, they will add it to what’s “available.”
These strategies are just a few things you can implement immediately to manage those biases and improve decision fitness.
WHEN WE LEVERAGE OUR BIASES, SOME THINGS CHANGE
Large-scale shifts in team thinking take time. Some things will start to happen immediately, however.
You’ll have more collective insight into the customer. Shorter decision cycles with more “just-in-time” context that includes different voices, including some that often don’t get into the conversation, means more voices will feel comfortable joining the conversation.
Less HiPPO wrangling. As a shift occurs in the power structure, the HiPPO will see that there are plenty of voices that are contributing and feel less pressure to “fill air.”
More usage. People will feel comfortable with product artifacts (research, strategy). Teams will have better inputs for their own decision making since they know where it is.
When a PdM manages this process, the team and org get better outcomes.
BOTTOM LINE: FIND BIAS, UNDERSTAND IT, LEVERAGE IT
Product managers, since they are usually outside of the solution business (read: making shit), are far more useful when they understand the mental pitfalls an organization may fall into. Since they have the mental space to look at things from both the customer and business P.O.V., as well as associate with the product makers, they should see where cognitive bias is helping or hurting an organization.
The best work we can do as PdM’s is to understand the outcomes we’re going for and use the environment around us to give it the best chance of success. Cognitive bias is a part of that environment. In particular, recency and availability bias have some silent consequences that affect the day to day that can lead to sustained mediocrity in product development.
And let’s be clear: it should be. It’s a messy world out there, and strategy is all about trying to bring some order to that chaos.
Like many things, though, the difficulty of the project doesn’t negate its importance. No matter how hard strategy is, you still need one. And the inputs that go into product strategy, from how your company is positioned in the market, to its current financial solvency, to the resources you have to allocate, to any number of other things that provide a cavalcade of options to align the company with your customers’ wants and the direction of your leadership. With so many different ways to go, how do you know if you’re doing it right?
How well the product performs based on market projections is often how an organization as a whole grades product. This performance is our responsibility, especially since product managers are usually either making, advocating or evangelizing the decisions that affected it. Accordingly, the best companies judge product leaders based on their ability to understand which inputs are important, manage them, and craft a strategy that ultimately brings the ideas to life successfully in the marketplace.
That organizational adjudication is all well and good. After all, good market performance is what the company wants out of a product. But it raises the question of how you should judge your own or your team’s product strategy on a granular level.
Well, like most aspects of product management, it depends. Every team is different, which means each one will require different metrics for grading its work. I don’t promise a silver bullet for this problem, but as a product person, you should be used to that by now.
What I can offer instead is a couple of key ingredients to any grading rubric. Effective product strategy lowers decision fatigue while simultaneously increasing team flexibility by providing psychological safety around decision-making. You need to think about how well your strategy does that. So let’s talk about it.
Every decision we make tires us mentally. Decision fatigue, then, refers to the tendency of our decision-making ability to deteriorate in quality over the course of a long session. This phenomenon should remain top-of-mind for product managers. After all, what is product development but a bunch of decisions we make in order to improve the probability of launching a successful product?
Every decision we make has a cost. And that’s true not just of our decisions, but those of our teammates as well. Each time the team picks a particular course of action, the next decision becomes harder to make and is likelier to be flawed. This process is heightened every time we struggle with a particular decision. The more work you have to do to decide, the more fatigued you get.
PRODUCT STRATEGY SHOULD MAKE DECISION-MAKING EASIER
Now that we’ve explored decision fatigue, let’s talk about the role of product strategy and how it helps teams stay focused.
Product strategy takes many forms. If you’re in a highly competitive industry, it could have guidelines on how you’ll attack the competitors. If you’re focused on growth, it’ll detail ways to get there. If you’re technology-driven, you’ll look for places where your technology will be more effective. So the particulars of your strategy will change based on your market and your goals.
What doesn’t change, however, is that when a person is on the strategy team, they need to feel comfortable making a decision. Feeling unsafe is a drain on your internal energy reserves. We’ve all felt how bad leadership and unnecessary ambiguity take their toll on our ability to make rational decisions and produce consistent business results. Psychological safety is a good bulwark against decision fatigue.
Your job as a product manager is to raise psychological safety by giving your people good product strategy. This means being as clear as possible about everything you can. Your strategy should clearly communicate the assets that the team has to work with, the boundaries that exist, and provide some narrative that team members can use to assist them with decision-making.
For example, let’s say I’m creating the strategy for an innovation team. I want my document to list assets such as the number of hours allocated to different disciplines within the project. I also need to alert the team to boundaries they face, like which tools and technologies are off the table. Finally, I need to tell the team about any narrative that should guide their work, such as the company’s target of raising revenue by 5 percent. The strategy lays all this information out in one place for easy access.
A good strategy gives a team concrete guidelines within which to operate. A team that doesn’t have to think about where they need to start or what might be off-limits is a team that can focus directly on the problem at hand. If your product strategy doesn’t provide enough background to help them make decisions, you’ll find that they either:
Make decisions that may not be the best ideas for the company at the time, or
Don’t decide on anything at all.
Tack onto this the fact that teams can and will do both of these things in the process of a project. Worse, they’ll do them with little to no consistency, making it hard to predict which mistake you’ll have to confront. All of this means it’s a matter of time until the team zigs when it should zag, especially as decision fatigue sets in.
Let’s be clear here, there is a difference between being descriptive and prescriptive. Good strategy is the former, not the latter. We use strategy to help teams understand what the world is, not exactly what to do. That’s why providing safety by giving the team context to make decisions is so important. When they feel safe, not only will they deliver more consistent outcomes, but you’ll also find they operate with more creativity as well. When team members feel that they’re not in danger of making mistakes, they feel more freedom to experiment and engage their creativity.
In short, a good product strategy is a document that reduces uncertainty and the overall number of decisions that must be made while also providing cover for those decisions. Your team should be able to take a look at your strategy and feel comfortable that following it leads to fewer headaches down the road.
TESTING YOUR STRATEGY
Let’s say you have a product strategy that’s ready. Your leadership team thinks that it will lower decision fatigue and empower people to make decisions. At this point, you should ask some questions to sharpen it up. Note that these can go too far, though, and balance is important.
Is my product strategy reducing the number of decisions my teams are making?
The best way to lower fatigue is to cut down on the number of “boring” decisions your team makes. Your strategy and the accompanying artifacts (design systems, roadmaps, etc.) should help people narrow the possible choices and paperwork involved in any decision so that they can focus on what really matters.
If you overdo things here, though, you’ll find that teams become robotic because they will wait for top-down direction on every subject. This kind of decisional paralysis is particularly bad for teams in complex environments, like innovation teams, who need extra flexibility since they run into failure so often.
Is my product strategy lowering the context needed to make decisions?
Another way to combat fatigue is to limit the amount of information someone needs to make a decision. Your strategy should identify which decisions are negotiable (i.e., what technology to use) and which are non-negotiable (i.e., if you have a limited budget). The accompanying artifacts (epics, initiatives, etc.) should reinforce which items are non-negotiable by using active, clear language. Avoid fluff.
Remember, it’s important to not fall into the trap of being prescriptive. Product strategy describes the world; it doesn’t prescribe which actions to take.
Is my product strategy making it safer to make decisions?
Product strategy should raise psychological safety by providing protection for front-line employees making decisions. Your accompanying artifacts (team charters, value docs, etc.) will enforce what is “right” by giving teams insight into what leadership and other stakeholders define as good work.
Don’t fall into the trap of overgeneralizing here, as you’ll then run headfirst into “toxic positivity culture” and people will be afraid to criticize anything at all. If everything is good, nothing is good. Standards matter.
Overall, you should focus on making sure your product strategy is helping your product teams work to reduce decision fatigue without reducing the quality of people’s decisions. Good product strategy is designed to make sure that your teams are all rowing together to improve the probability of good decisions. Eventually, that leads to good customers and a great business.
Well, I think we should start by breaking down both terms. Full-stack, in the tech sense, describes someone who is a jack-of-all-trades, but (generally) a master of none. You usually see this term on engineering teams, where job descriptions ask for “full-stack” candidates by requiring skills that are critical for both front-end and back-end work. The expectation is that this individual can fit into any project and drive results.
Companies generally hire product managers (PMs) to foster and strength alignment between teams, and also to mitigate risk. When the product team is effective, they end up being a force multiplier for all of your resources. When they’re struggling, they become roadblocks to those teams that are creating value for the company. There are several types of PMs, and in this article, we’ll focus on the main three: the product-delivery-focused PM, the growth PM, and the strategist PM.
A full-stack PM would combine all three of these types to make the ultimate “full-stack” product manager. Let’s explore these three types and the skills that are most important to each.
The product-delivery-focused PM
This type of PM is responsible for delivery. They often work with engineers often and are judged by the value of the features they ship. When product delivery is going well, it helps teams move forward. But when it isn’t, the team gets stuck in red tape and loses focus on the value of the products the team is putting into market.
The product-delivery-focused PM needs to have solid project management skills to keep everything moving on schedule. They also need to be fairly comfortable with the internals of a product, since they are going to be partnered with the engineering team to understand technical debt and feature value. In most places, the “typical” PM is this type.
The growth PM
This type of PM is focused on the business. They work frequently with sales and business analysts and are evaluated by metrics like virality and nominal pricing. When a company is growing, the business is moving toward its goals and increasing its market share. When growth is stagnant or even decreasing, the team ends up trying to balance disparate objectives and KPIs lose their meaning.
The growth PM needs to be comfortable in sales, marketing, and pricing to keep growth moving up and to the right. In addition, they need to be comfortable with the sales process (whether it is B2B or B2C) because they will be making changes often. Andrew Chen is known as the originator of this position and has written a ton about it here.
The strategist PM
This type of PM is focused on the market. They work with designers and marketing teams and are judged by the alignment of the portfolio. Often, they are also trusted to handle new ideas. When this PM is doing his or her job well, the business is aware/protected from new players entering the market and has some idea of some adjacent markets to explore. When it isn’t, the team is caught off-guard.
The strategist PM needs to be a mix of marketer and UX’er and be ready and willing to spend a lot of time with customers and other stakeholders. In general, they end up being the connective tissue of your strategy, tying together intuition and metrics like retention to tell a story. Plenty of companies utilize them when they feel comfortable in a specific market.
So, how do you merge all three?
Alright, let’s be truthful. All of that sounds impossible because it is. The term full-stack is a symptom of teams trying to maximize “efficiency” when it comes to labor costs, without fixing the core issues of the company. If you find the term “full-stack product manager” on a company’s careers page, you should run away, far and fast.
If your team puts a job description up, it’s worth asking a few questions, such as:
What problem does this hire solve for us?
How will they integrate with the company?
How will this hire position us for the future? What bet(s) are we making by bringing this person in?
If they cannot answer those questions, then your leadership team is fulfilling headcount just to do so. It might be time for you to save yourself and find a team that is clearer about what they’re looking for in a new PM hire.
As a product person, you need to bring about organizational alignment through product strategy while also keeping things running smoothly with product operations. I don’t need to tell you this is a delicate balance. And without time to sit and think, you’ll end up making rash decisions based on your biases.
So, what is bias? Well, our good pal Wikipedia defines bias as:
“Disproportionate weight in favor of or against an idea or thing, usually in a way that is closed-minded, prejudicial, or unfair. Biases can be innate or learned. People may develop biases for or against an individual, a group, or a belief. In science and engineering, a bias is a systematic error.”
The first sentence of this article was about “thinky” work, so let’s add something to our bias definition that focuses on the brain: the word cognitive.
Cognitive biases
Here is the definition of cognitive bias, once again from our friends at Wikipedia:
“A cognitive bias is a systematic pattern of deviation from norm or rationality in judgment. Individuals create their own ‘subjective reality’ from their perception of the input. An individual’s construction of reality, not the objective input, may dictate their behavior in the world.”
The word system is there, too. In fact, we should discuss systems before we go any further (especially because product exists somewhere between science and engineering). Our bias is an error in a system. If you don’t think your work involves systems, it does. And if that took you by surprise, take some time to audit your product organization to see just what systems exist. Org charts and meeting lists are a great way to start, as are team retrospectives.
Once you have a basic understanding of the system(s) your product development team exists in, this article may be helpful. If not, bookmark this article and come back to it after you’ve got a clearer picture of the system(s) your team is part of.
If you’re still with me, I’d like to spend some time talking about three biases that are affecting your teams, how they affect your teams, and some ways to identify them. These biases — confirmation bias, availability bias, and recency bias — can leave a product team spinning its wheels and keep your organization from reaching its goals.
Confirmation bias
Wikipedia defines confirmation bias as:
“The tendency to search for, interpret, favor, and recall information in a way that confirms or supports one’s prior beliefs or values. It is an important type of cognitive bias that has a significant effect on the proper functioning of society by distorting evidence-based decision-making.”
Confirmation bias is the most common bias within product teams. In fact, it’s the “patron bias” behind feature factories. Since every result seems to “make sense” to the product team, they end up proceeding, full speed ahead, with their plans. Feature factories are incentivized and tracked by “feature release velocity (FRV)” and “can’t afford” to stop shipping things as rapidly as possible.
The problem? Your product strategy is about customer outcomes, not how many features you’ve created.
Your team may be experiencing widespread confirmation bias if:
Research always “makes sense.” If user research always goes smoothly and never reveals anything surprising, then it’s worth questioning how deeply you are interrogating the world around you.
There is no tension in meetings. Teams come from different perspectives, and there should be a healthy level of conflict that comes from those perspectives.
Recency bias
“What just happened?”
If we are always thinking about that, then we’re focused on recency bias:
“Recency bias is a cognitive bias that favors recent events over historic ones. A memory bias, recency bias gives ‘greater importance to the most recent event,’ such as the final lawyer’s closing argument a jury hears before being dismissed to deliberate.”
Recency bias means we aren’t actively listening to different perspectives — we’re just checking boxes until we hear the last word. Too often, this ends up being the highest-paid person’s opinion (HiPPO). When product operations is very top-down or if there is no rigor behind your decisions, then your teams are really just waiting until the end of the meeting for a decision. The problem here is that the work you are doing ends up not mattering to the product strategy. And in the long run, teams can slowly lose their agency, which harms operations and slows down processes.
Some symptoms of recency bias include:
Meetings not having any agenda or facilitation. If no one is managing the conversation, our brains will just remember the last thing we heard.
The “roadmap” being the list of the HiPPO’s thoughts. The tactics you use to get to the outcomes you want should come from a variety of sources. If there’s only one, you have a problem.
Availability bias
Relying on “what’s on hand” might seem like a smart practice, but it can lead to trouble:
“The availability heuristic, also known as availability bias, is a mental shortcut that relies on immediate examples that come to a given person’s mind when evaluating a specific topic, concept, method or decision.”
I left this one for last because it’s a bit complicated. While the other two biases are almost always bad, this is one the pros can use to their advantage. Unfortunately, many teams can’t, which means we get stuck with the downsides, including lower decision quality. Our work isn’t a game show. How quickly you hit that buzzer doesn’t really matter — outcomes do. This bias leads to shallow outcomes and releases that may get even worse when combined with the other two biases mentioned which is an operational waste.
Your team might be struggling with availability bias if:
You’re reliant on quick decisions/buzzer logic. For example, you spend entire meetings talking about potential outcomes, only to take the first option available.
Research is being ignored. Research almost always comes with curveballs, and if the decisions you come to haven’t considered them, you’ll end up with shallow outcomes.
The importance of time
Biases come into play when teams don’t have time or space to carefully consider their decisions. In short, they are acting too fast with little time to process. If you feel that the team just moves from project to project, you’re most likely running right into bias traps. As a result, you’re probably making lower-quality decisions that can hurt your team long-term, both in how product development operates and when it comes to strategy.
The solution is often simple: SLOW DOWN. Identify what’s important to the system you operate in and spend time paring away any processes that don’t make sense to your product strategy and operation. This includes projects as well. More often than not, it means getting rid of things and prioritizing so the team has time to think.
This is “thinky work,” and without allowing time for real thought, you’ll ultimately need luck for success. And I’ll end with a word of caution — luck is biased toward the patient and the prepared.
BLUF Your Way to Success – Adam Thomas on The Product Experience
The one thing every product person needs is a new acronym that comes from the military, and Adam Thomas is here to help. Sarcasm aside, Adam’s made good use of the BLUF technique: Bottom Line Up Front, a short template, clearly laying out what the team is working on and how they plan to do it. He joined us for a chat about alignment, how this complements Mat LeMay’s One Page/One Hour approach, and why his template stretches onto a second page.
In this episode of the Product Science Podcast, we talk with Adam Thomas does to create a disciplined and clear approach to product research.
Adam Thomas is a product manager with 10 years of experience as a “wartime” product person. As Director of Product at Informed, he built a product research and development practice from the ground up, teaching his team solid research methodologies as well as getting buy-in from stakeholders to build things the right way.
In this episode of the Product Science Podcast, we talk about what Adam does to create a disciplined and clear approach to product research.
What was Adam’s experience like founding a startup at the age of 19? How did he transition to FiTech as a mainframe programmer? What were the differences moving into a mainframe architect role, and how did that prepare him for a future in product? How did Adam develop the EdTech startup the Arcade School? What did an advisor say to him that led him to kill the project? What lessons carried over into his role as a product leader today?
What is the difference between working in a product management role in large enterprises versus the traditional Silicon Valley model? Why is it important to understand the politics behind shipping something at these kinds of organizations in order to be effective? How did those experiences influence Adam’s work at Informed building product from the ground up? What were his priorities when he had the ability to set them himself?
How can a Product Requirements Document be useful even if you don’t show them to anybody? Why did Adam make younger product people go through the exercise of writing a PRD? How can you learn to ask the right questions in product? Why is writing out a list of assumptions at the end of the document so important as a starting place for product research? Why does Adam push product leaders to always identify their stakeholders and why they care?
What did product research look like at Informed and what challenge did Adam face in building out a research discipline and practice there? How do you get buy-in for your research? How do you get buy-in for making decisions based on your research? What is a falsifiable hypothesis? Why is it so important to be able to prove your expectations wrong with research?
How do you train people new to product in experimentation? How do you teach people to identify bad research, and understand why it was bad? Why did Adam do a study as soon as he started at Informed, and how did he use it to teach a lesson to his team? How does he think about the political side of research?
Quotes From This Episode
Folks tend to dismiss, in telling the story of whatever they’re trying to build, the point of view of the stakeholders.
I feel like a lot of times when somebody has tried to do research they did it badly. And now their mental model of what research looks like is just a waste of time.
For a usability study…You need to have a falsifiable hypothesis. You need to have clear questions that don’t lead the person. You need to know what you’re ultimately trying to get out of this both politically and also through the person. You need to be very clear with your script.
Transcription
Holly Hester-Reilly:
Hi, and welcome to the Product Science Podcast where we’re helping start-up founders and product leaders build high-growth products, teams, and companies through real conversations with people who have tried it and aren’t afraid to share lessons learned from their failures along the way. I’m your host, Holly Hester-Reilly, founder and CEO of H2R Product Science.
Okay, so this week on the Product Science Podcast, I’m super excited to have a conversation with Adam Thomas. So, Adam, welcome.
Adam Thomas:
Hi, Holly. How are you?
Holly Hester-Reilly:
Well. For anybody who’s listening to this later, we are recording in the middle of the COVID quarantine phase, which we don’t exactly know when this will end. I’m doing as okay as anybody can be doing, kind of. How are you?
Adam Thomas:
I’m in the same place. With this pandemic happening, it’s a blessing to be able to talk to someone else as we’re kind of stuck in our apartments and places. I’m sure the folks listening are in kind of the same place of this is still going on when you hear this. Yeah, thankful to be healthy and I’m hoping that everyone else here listening to this is in the same place.
Holly Hester-Reilly:
Cool. Well, yeah, let’s try to distract everybody from all of that and talk about product and software and building good stuff.
Adam Thomas:
Let’s do it.
Holly Hester-Reilly:
Why don’t we kind of go back a little bit? If you could tell me sort of how did you get started in working in tech? Did you start in product? Did you start in something else? How did you make your way over to product management?
Adam Thomas:
I made the mistake that a lot of young people do and started with my own company. When I was 19, I started building this company called JRLI Media. The product that I produced was called The Gamer Studio. It was a media start-up in around 2007, 2008, and we focused on just everything news kind of at the tail end of when you could make money doing ads in any type of way. That’s kind of where I got started in tech.
Then after learning all types of bad habits after running that for about four years, I ended up in, I like to call, old-school fintech at a company called ETCC where I was an engineer. Mainframe programmer, actually, which I’m not sure how many folks listening to this have had any contact in the world of mainframes. But I spent six years there.
Holly Hester-Reilly:
Whoa, whoa, whoa. I’m not going to let you keep going there. You programmed mainframes? I don’t think I’ve ever talked to somebody who does that or did that. How did you end up doing that?
Adam Thomas:
So I went to an HBCU, historically black college university, and a lot of the financial companies and a lot of big data companies were targeting HBCUs around 2009, 2010, to help hire for their mainframe teams. They were paying well. Somebody proposed me. I came up to New York and viola, that’s what got me here to New York. Then also that’s what got me into mainframes. Best job available.
Holly Hester-Reilly:
Why is it the best job available?
Adam Thomas:
At the time, we’re coming out of a recession. I’m talking to folks that are making fractions of what they were offering just coming out of school. People were taking the first job they could get. It had a good salary. It had a good company. It felt like the culture was good when I went up there. It was something new and exciting, at least for me. Mainframes aren’t necessarily known as new and exciting.
As somebody that was programming, I built my first start-up content management system from scratch. I built that with PHP. It was pretty in-depth with modern technology at the time or what is seen as modern technology. Mainframes is different, it’s new, it’s weird. Something to learn.
Holly Hester-Reilly:
Yeah. Cool. So you were an engineer there and then what happened after that?
Adam Thomas:
Then, after three years of being a mainframe programmer, I ended up switching over to being a mainframe architect, which is pretty much like product, essentially, on the mainframe side. I was managing products. I was doing research. I was building interfaces. The whole software fulfillment lifecycle was up to me. It took me a couple of years of working in product on this side of the fence of distributed computing. There’s mainframe computing and distributive computing. Distributive computing is generally what people are listening to this on, probably, or using their laptops. Coming over to this side of computing to know this is essentially the same job but on mainframe side. That is where I started product.
Holly Hester-Reilly:
Yeah. And were there any people who were called product managers when you did that or was it just mainframe architects?
Adam Thomas:
They would just call it mainframe architects. When I would go to conferences and things like now with the background I have in product management, it’s like, “Oh, this is basically product.” But then, in that world, you’re just a mainframe architect.
Holly Hester-Reilly:
Yeah, yeah. I think there are a lot of people who come up and realize at some point that they’ve actually been doing product but they didn’t know that anybody called it that; weren’t familiar with the term and what not. I mean, we still come across people all the time who are like, “What does that mean? What do you do? What exactly?” It’s a classic question. Where did you go from there?
Adam Thomas:
So from there, I ended up getting founder fever again. I started another company with an old rival, actually, by the name of Anthony Fraser. We started a company called Arcade School which was an ed-tech platform designed to help college students in the world of video game and design move towards full-time jobs and the corporate atmosphere in a more successful way. They had a high burn-out rate, high drop rate from folks that are graduating even from the best schools like Carnegie Mellon. There was a whole lot of money being sunk into the new folks that just weren’t making it so we were trying to bridge that gap to increase the rate of success.
Holly Hester-Reilly:
How did you stumble upon that problem as the problem to solve?
Adam Thomas:
We looked at teachable at first. I think we started with this idea that, “Hey, we’re just going to teach people how to build video games.” Then, after a little bit more research and talking to recruiters and talking to folks that work in the industry, we started to stumble on to what this problem was. There were just a whole bunch of students that were very frustrated. A whole bunch of universities that just weren’t quite sure what to do with the students that matriculated through them. And then, also, with corporations that were just lost in terms of their human capital problem. It’s the first time I ran into the term human capital.
Holly Hester-Reilly:
So how did that go as a business, as a product?
Adam Thomas:
Failed. After about six months bootstrapping, got a few folks on board. Going to fundraise, just didn’t like what I was hearing. I had breakfast with an advisor one day and he was just like eh. He’d worked in the ed-tech space for a while. Was on the board of a pretty popular school here in New York. He was telling me like, “It’s ugly out here right now. We’re losing money and we’re pretty popular.” I don’t want to say the name of this place. But he was saying, “Yeah, we were losing money. We’re pretty popular. I like your vision. I like what you’re trying to do but the financiers aren’t really digging this right now. BCs aren’t really digging what you’re saying. They’re going to try to make you turn into this other thing that’s not really working.” So if you keep hearing, “Save your time and your energy and get out.”
Holly Hester-Reilly:
Must have been hard.
Adam Thomas:
Yeah, yeah. No. I had to have the conversation I think a lot of founders… If you’re in this long enough, you have the conversation with folks that believed in your vision and what you were trying to do. I had to tell them, “I’m sorry. It just didn’t work.” Yeah, it was quite tough. Kind of threw me into a bit of a depression there for a little bit.
Holly Hester-Reilly:
You are not the only founder that I know who has been through that cycle. It’s hard when you get to the point where you didn’t achieve take off. It’s hard to not go through a depression as you’re coming out of that.
Adam Thomas:
Most definitely. It’s funny. If I knew then what I know now, I guess, there would definitely be a lot of things I would do differently. But I think it was a critical part of my life. It shapes the product leader that I am today. I really appreciate it and none of the folks hate me. We still keep in contact with everybody that went with me on that journey. If they don’t think I’m a flaming piece of garbage then how mad can I be with myself, right?
Holly Hester-Reilly:
I think that’s a great way to look at it. So interestingly to me, your story, the timing was very similar. I also got into product by way of being part of co-founding a company and doing that first. It was founded in 2007 so same time frame. I remember well what it was like being in the New York start-up scene in that time. I was in New York already. That didn’t survive, either. We went through the same cycle of, “Okay, what do we do with this?” I don’t know about you but to this day, I have friends of mine that were friends at that time that I feel like they still think that it was a bad decision for me to have founded a start-up instead of going and getting a job. I’m like, “But I wouldn’t be able to do what I do now.” This is a big part of how I became the product person that I am because I’ve lived through the things you can do right and the things that go wrong. They’re not joking when they tell the statistics on failure.
Adam Thomas:
Yeah. Very much so. The likelihood that all the people you confide in, all the founders that you talk to, there’s a high rate of failure. You’ll all look back now, a couple years later, and go, “All of our start-ups are gone.” It was just a thing we did but it’s a thing that binds us, people that have gone through that failure.
Holly Hester-Reilly:
Yeah. So after this second round of the founding bug, what happened next?
Adam Thomas:
I ended up getting hired at a company called Philosophy, which, Chris Butler who’s also been a guest on this podcast was the person that hired me there as a product strategist. From there, I spent a lot of time working on a whole bunch of different projects. The great thing about consulting at Philosophy was just the diversity of things you got to work on. It was the first time I had dealt with things like AR and VR. It was the first time I dealt with mobile apps. I had a little bit of time at DTC working on AI so I came to there with a little bit of knowledge around AI and the process of actually turning something that is using AI into something that’s product-ready. But this was the first time doing it on this side of computing. So very cool to work on chatbots. Very cool to work on AI design systems for these big companies that I would have never guessed to work for.
Holly Hester-Reilly:
Tell me a little bit about when you’re working on that kind of project, you’re often doing product in a different environment than the Silicon Valley product manager because you’re working within enterprises and big old companies. What was that like?
Adam Thomas:
Coming from someone that started their own thing and kind of worked, it was frustrating. I did have experience at DTC and some other huge enterprise companies, so my experience there helped me navigate it a bit more and understand the politics that are behind getting things out the door of those places. Some of the softer skills. Some of the things you probably don’t have to do thinking about Silicon Valley-based start-ups where the org chart is very convoluted and it’s a lot of dinners, a lot of coffees, a lot of conversations that don’t seem like you have to have but you do in order to get something moving.
I think on the flip side though, it teaches you about patience in terms of getting things out the door. It also teaches you politics which, I know this is something I think we’re going to touch on later, but I think the politics of getting products moving, they’re everywhere. Learning how to do it starting in finance and then also working in these big companies that I worked at when I was working with Philosophy was almost a master-class in learning how to navigate things to get things done.
Holly Hester-Reilly:
Yeah, for sure. I think you’re right. We probably will touch on that a bit later. I know that you’ve got another step to your journey after Philosophy, right?
Adam Thomas:
Yes.
Holly Hester-Reilly:
So tell me what else is in your portfolio of experiences that we might use?
Adam Thomas:
Gotcha. So I have a very short start-up that shall not be named. Then the last major step in my career was being director of product at Informed. Informed, where I was at most recently, the last few years, is a company that helps third-party sellers on marketplaces such as Amazon, eBay, and Walmart, price their items to get better revenue through search results.
Holly Hester-Reilly:
Cool. And so there you got to be presumably in a smaller team than those big enterprise projects?
Adam Thomas:
Yes, yes. A lot smaller team. Essentially, I built product from the ground up there. Basically, I got to use everything that’s I’ve used in the past in order to craft the culture and get the product out of this mature state it was in and into something that’s new.
Holly Hester-Reilly:
Cool. How old was the company when you started?
Adam Thomas:
They would say seven years. Let’s just say seven years.
Holly Hester-Reilly:
Yeah. I know. Sometimes founders count funny.
Adam Thomas:
Yes.
Holly Hester-Reilly:
That’s one of the things that I wanted to talk with you about too because I know that while you were there, you really got to take the things you learned throughout this career of early-stage start-ups and products within the enterprise and working with people like Chris Butler to a company where you could really apply it and help build out their practice. What were some of the things that you got to do there that maybe had been really hard to do in some of the previous jobs?
Adam Thomas:
I think one of the things that was really cool when I got there was the ability to just pick things to do; pick processes, pick tools, pick anything. Since it was a small company but it was profitable, I had a pretty sizable budget compared to sometimes when you’re consulting you might be working with a company with billions or super billions of dollars. But they’ll be like, “Hey, you got $200 to figure this out.” Here, I had a pretty sizable budget to work things out so it was nice to be able to build a research practice.
Also in terms of running the product process as a whole was really cool to be able to take some of the ideas that I’d been learning and figuring out in theory and then apply them with folks that haven’t been… Like at Philosophy, I was probably the least experienced product person there. Here I was the most experienced product person. So all of a sudden I have all these young, associate-level folks and I got a chance to apply some of the theory that I have.
Holly Hester-Reilly:
Yeah, so tell me some more about that. What are some of the theories that you applied and how did you apply them?
Adam Thomas:
One of the things that I got to do, which is something that I’m super proud of, is I got a chance to manipulate the PRD structure and change it into something that’s a little bit more useful to folks outside of the product team. I feel like that’s what everybody does. Everybody has their own version of PRD that they like to play around with. I don’t know if this is weird to folks but I also love, on regular PRD, I think it’s a great document which probably has some contention with folks. It’s not something to show anybody.
Holly Hester-Reilly:
Picking up on that, if you see a PRD as a useful document but not to show anybody, what is it for in your experience or your usage?
Adam Thomas:
I think a PRD is a great document to get your ideas down. It asks a lot of questions that if you’re not trying to be rigorous you can dip, dodge, and duck around to get through. But forcing especially younger product people to go through that process. I often got a lot of, “Why are we doing this? We never had to do this before. Why are we writing down these metrics? Why are we doing?” But having them have better questions to ask the teams around them as they were building out products and then also having them more confident in the work and the research that they were doing combined with the idea of what’s on the ground, I know it’s because of forcing them to write these things.
Holly Hester-Reilly:
Mm-hmm (affirmative) Yeah. So making them think critically about why they’re building this product and what metrics it’s supposed to achieve. What to measure to know if it’s successful.
Adam Thomas:
Right.
Holly Hester-Reilly:
Is that what I’m hearing?
Adam Thomas:
That is what you’re hearing.
Holly Hester-Reilly:
So one of the things that I think is interesting is that I feel like the word PRD, the acronym. The word is product requirements document. The acronym is PRD. Fix my own language here. But I think the phrase, the acronym, polarizes people because similar to how there are other phrases in product that polarize people like, “Is the product manager the mini-CEO?” Some people will be like, “Yes,” and other people will be like, “No.” I think the idea of the PRD is one of these things. And in many cases, I think that comes from each of us having our own assumptions about what a PRD is, which come from our own backgrounds instead of experiences of what it was like in whatever companies we were in that used it. Or if we’ve ever been in a company that’s used it.
The more people you work with who are younger, the more likely you are to come across people who have never come across one. So I think it’s really important to share what you mean by that. And I’m curious if you could tell us, since you mentioned sort of reimagining it, what are some of the things that you had people think through and answer as part of the process of thinking through what the product requirements document would include that was helpful for these young products people that you were guiding?
Adam Thomas:
It’s kind of touching because I was just thinking about a young researcher that just built her portfolio and she was like, “Adam, I did your version of the PRD and I put it in my portfolio because it really helped me.” It came right to mind. What are some of the things that I think are required there that was a little different? I’m really big on story so having those folks having to create somewhat of an abstract on the top of the PRD. Have a way to tell or talk about it because, knowing that no one is going to read the whole thing, but having something that’s shorthand that you’re able to talk about that kind of summates everything that’s in that document is something that I really pushed at Informed.
Another thing that I really pushed at Informed were their assumptions that were being made. I made it a point at the end of every document just to write a list of assumptions that I saw that the product person was making or asked them to write what they saw as they were writing through the document. I would tell them that, “Okay, this is the start of your product research, right? We have to get to the bottom of these assumptions. How confident can you be in them?” I think the team found it very helpful to have to sit there and think about just how often we tend to just assume things and let it go. It functioned as a pretty big check.
I don’t think there was anything else that was relatively different other than that for those internal documents that I had them write. Same metric success. Who are the stakeholders? I guess this is different. Who are stakeholders and why do they care?
Holly Hester-Reilly:
Tell me more about that.
Adam Thomas:
I know politics is being a topic or theme that we’re kind of touching on. I think one of the things that folks tend to dismiss in discussing or telling the story of whatever they’re trying to build is what is the point of view that other folks that are stakeholders are coming from. It’s super important as you’re trying to get resources or you’re trying to get people to believe or moral to go up, you have an understanding of why they care.
Holly Hester-Reilly:
Yeah, or if they care. Why should they?
Adam Thomas:
Or if they care. Yeah.
Holly Hester-Reilly:
A lot of time people just come at it assuming that these other people are going to care. I’m going to give them documents to read and they’re going to read it because they care. But maybe they don’t care and you need to understand why.
Adam Thomas:
Most definitely. Sometimes not caring is fine. It saves you time. If you know this engineering manager doesn’t care or believes you or whatever, it’s not really affecting their day, then you know you don’t have to give them updates a million times a day. Hey, I can use this understanding to send an email out at the end of the week and say, “This is what your engineers are working on.”
Holly Hester-Reilly:
Yeah.
Adam Thomas:
Or the marketer, they really see that this feature has the ability to really, I don’t know, increase referrals. You know how to keep them up to date and keep them abreast and give them stuff that they can send out to the folks that are anticipating this so that they can… You have an understanding to send that stuff out to help boost folk’s excitement about what you’re building, right?
Holly Hester-Reilly:
Yeah.
Adam Thomas:
All these things become possible just by thinking about, very early in the process, why do they care? What is their point of view? What do they want out of this?
Holly Hester-Reilly:
Yeah. You mentioned as well, and let’s say, sort of this process that you’ve built there. They start with this document and it makes them think critically about what they’re doing and why, who cares about it, how do they measure it, and what is this initiative, right? You said it’s the beginning of their research so tell me a little more about what did product research look like? And what kind of challenges did you face in building out a research discipline and practice there?
Adam Thomas:
I’ll tell you, Holly, I’m sure this is something that you’ve faced a lot doing the work that you do. There’s barely any discipline. Barely any consistency. A lot of gut reactions.
Holly Hester-Reilly:
What? You don’t say? People like to just go with their gut?
Adam Thomas:
No documentation, no anything that speaks to a very mature research practice. When I got there, I did this with clients a lot. I would say, “Okay, give me everything you’ve done prior.” I know with clients, it would give me an understanding of where were they? How do I need to talk to them regarding research? Are they at the very beginnings? Is it good research? Is it bad research? If they have a lot of it? Let’s kind of break it down here so I have a game plan going in.
At Informed, it was more the former. It wasn’t much of any research to speak of, even though before I got there they swore they had product folks and they swore they had other things happening. At a certain point, if there are folks doing the work there should be something that shows the work being done. They just… Yeah, yeah.
Holly Hester-Reilly:
Yeah, so you faced them having not much of a practice there. One of the things that I come across a lot of times when I do work with people where whether it’s the person I’m working with directly and their team or it’s the people around then one step removed, is disbelief that it’s worth it. Whether they think that it’s not needed or they think that it’s not possible to get useful learnings from, it’s not uncommon to hear, “Why would we invest in that?” I’m curious, did you come across that? Was there a pushback on it? This maybe is a place where it comes back to sort of these politics of like, “Well, it’s not just what does it mean to do good research, it’s also how do you get buy-in for that research? How do you get buy-in for making decisions based on that research?” What does that look like for you?
Adam Thomas:
Right. I feel like a lot of times, I don’t have any data on this, but somebody has tried to do research. They did it badly and now they’re mental model of what research looks like is just a waste of time, full of these quotes that no one is going to use and full of this bad data that doesn’t really tell us anything. When assessing and when getting to Informed, looking at some of the research I saw some of that. I saw quant data surveys that had maybe six or seven responses and folks making decisions based on that. I saw all research that were hypotheses that weren’t falsifiable. I saw…
Holly Hester-Reilly:
Let’s pause. Let’s pick on that for a second because I don’t know that I’ve covered that topic before. What do you mean a hypothesis that is not falsifiable?
Adam Thomas:
Well, Carl Popper says… No, but not to get into it too much, a good hypothesis needs to have the ability to be false or else we’re just going to believe whatever we think. There has to be a very clear bright line reason why this won’t work or this will work.
Holly Hester-Reilly:
Yeah.
Adam Thomas:
And the sharper it is, the better it is for the experiment. When I say the hypotheses weren’t falsifiable, they’ll say, “We’re doing this research study to see if someone likes this.” I can’t qualify like. I don’t know what that means. You can create what like is in your head at any given time.
Holly Hester-Reilly:
Yeah.
Adam Thomas:
As opposed to saying, “I think that out of three folks, two people will do X and that tells me if this is why, that’s far more… ” I hate three but just using that as the first number that came to my head. That tells me what a hypothesis is and I have something very clear to really speak to what we’re trying to understand.
Holly Hester-Reilly:
And there’s a way for it to be wrong. If your hypothesis is two out of three people will do X and then one out of three people does X, you’re like, “Whoops, I didn’t get that quite right. There’s something there.” Yeah, absolutely. If you were working with younger product people who were newer to experimentation in the world of product, how do you train them?
Adam Thomas:
I think there are three things that you have to really nail to build a really solid research practice. The first thing is you have to train that discipline. They have to know why the research in the past was bad. For quant, you just got to give them, I think, at least two things. One, you have to give them an understanding of statistics. Seven is not going to be a sample size that’s going to tell you anything why. You have to tell them about confidence. You have to tell them how to get sample sizes. You have to tell them about margins of error. You have to tell them all types of things, these things that will help them understand why they need X amount of people to answer or else the survey is nonsense.
You also have to tell them how to build good survey answers, or questions. I’m sorry. Questions and answers, honestly.
Holly Hester-Reilly:
Yeah. I was just going to say, “And answers.” Yeah.
Adam Thomas:
Both. Both matter. You have to teach them how to screen correctly when looking at surveys. You got to have gotchas that help them understand this is useless data, let’s get this out of here. Giving them the understanding of how to do that stuff on the quant side is super important. On the qual side, it’s creating research outlines, real research outlines that take work.
I remember when I first got there, I had a designer tell me for a usability study, he was just like, “I really don’t understand why I’m spending this time. I just want to get them in front to see if they do the thing.” After walking him through the reason why, which is essentially you need to have something clear. You need to have a falsifiable hypothesis. You need to have clear questions that don’t lead the person. You need to know what you’re ultimately trying to get out of this both politically and also through the person. You need to be very clear with your script. When he did it afterwards, he was like, “Oh, this data seems a lot clearer.” And it’s like, “Yes.” You’re starting to get things that are useful for you to take and give it to someone and say, “This is why I’m making this decision.” As opposed to just people feeling like it’s from your gut and that you don’t have a lot of data to really back that up very cleanly.
There’s also recruitment discipline. I mentioned screeners in the past with the quant stuff that I brought up. There’s something, I’m sure you’ve heard this before, I don’t want to bother the customer. I’m scared to bother them. I don’t know if they want to hear from me.
Holly Hester-Reilly:
Yeah.
Adam Thomas:
Meanwhile, they don’t know their customers are biting at the chomp. They just can’t wait to tell you stuff.
Holly Hester-Reilly:
Right.
Adam Thomas:
I remember the first time, and this goes into being a model which is the second part, being a model for them I remember I got there immediately and did a beta study, just immediately I think the second week I was there. I think most of the participants were like, “I don’t need a… ” They didn’t even want compensation from me. They just were like, “I can’t believe someone’s finally reached out to me to talk about X. I’m super happy to tell you what’s going on. You want more? What’s your email? I’ll send you all my thoughts.”
Holly Hester-Reilly:
Yeah.
Adam Thomas:
Customers are super excited to hear from you. All it takes is an email, for the most part. If you have tools like Intercom or Mixpanel or Pendo or whatever, this makes this super easy to do. Really, a simple email just saying, “Hi. I want to hear from you,” will get you a whole bunch of stuff. You tighten up their discipline around your quant, your qual, and also your recruitment.
The next step is modeling that behavior. As I said, one of the first things I did was just do a study just immediately and also critique the study they did. Showing them, one, this is how I got the data. Presenting this over to leadership. Showing them how I did that and having leadership listen in a way that they haven’t before. I think for them was a good way for them to see, “Hey, people will listen to research.” There’s a way that people do listen to this stuff.
Holly Hester-Reilly:
And what is that way? What, for you, has made it different so that the leadership was listening?
Adam Thomas:
I think it goes back to understanding what their motivations are. It’s about getting the data that they care about and also presenting them with the work that you did. Showing them that you do show your work. Show them that you do understand what they need. Giving it to them in the most efficient way possible. I did the big show once a quarter, which was all the research all bundled up, all summarized all beautiful. It was really a one sheet at the beginning of the presentation that I sat and had them read. I’m an Edward Tufte fan. Of course, I’m going to tell them to read silently. Showing them that, yeah, we do the work but the truth is they all knew that by the time we got there.
Before the big show, it’s a constant feedback cycle of me showing them what they want to know. Sometimes they want video. Sometimes they want face to face presentations. Sometimes they want text. I had an engineering manager that loved to read the transcripts. He was just like, “Send me the transcripts. I just want to read all of them.” Happy to do that. Showing them that, eventually, my team is able to give you all this information how you want it so you can make better decisions on your own. Opens everything up.
Holly Hester-Reilly:
Yeah. Cool. Are there any other tips you have on the politics-side of making that research useful, maybe outside of leadership amongst the engineers or any other teams that you’ve kind of worked through that on?
Adam Thomas:
I think the politics matter internally too, to the product team, research team. As the leader, I think it’s important that you model this stuff working. You model a way to disagree. You model a way to, I guess I want to say, get your will across the organization. That gets the product closer to the books they read or the blogs they keep up with or the podcasts like this that they listen to. I think there are probably a lot of product folks that will listen to this like, “My organization doesn’t do any of this.”
There’s an opportunity for product leaders to kind of jump in and start to model that for the folks internally, politically, so that they get more confidence as they go out on their own. You can’t be there for every interaction. You have to give them the tools to be able to do so in a way that helps them not just for this job, and this is something that Butler told me a lot, “I’m not here to help you for this job. I’m here to help you for the next one.” Giving them the confidence and the skills to move forward with their careers is ultimately, I hope, a legacy for that team and the folks there.
Holly Hester-Reilly:
Yeah. Absolutely. I think we’re going to need to wrap it up because we’ve been talking for a while. I’m wondering where people can find you if they’d like to follow you and hear more of what you have to share?
Adam Thomas:
Sure. So just finished my website. Done, the remodel.
Holly Hester-Reilly:
Congratulations.
Adam Thomas:
Thank you. It’s funny because it’s one of those types of projects where you go, “I’m the boss of this. They can just wrap it up.” Then you just spend weeks and weeks and weeks figuring it out. So you can find that at theadamthomas.com and then also you can find me on Twitter, same craziness, at thehonorableAT on Twitter.
Holly Hester-Reilly:
Wonderful. Awesome. Well, thank you so much for your time, Adam. I really appreciate you sharing your experiences with our listeners and getting to talk about product with you.
Adam Thomas:
Thank you, Holly, and thank you for inviting me. This was a wonderful, wonderful conversation.
Holly Hester-Reilly:
Product Science Podcast is brought to you by H2R Product Science. We teach start-up founders and product leaders how to use the product science method to discover the strongest product opportunities and lay the foundations for high-growth products, teams, and businesses. Learn more at h2rproductscience.com. Enjoying this episode? Don’t forget to subscribe so you don’t miss next week’s episode. I also encourage you to visit us at productsciencepodcast.com to sign up for more information and resources from me and our guests. If you love the show, a rating and review would be greatly appreciated. Thank you.
This adage – one that many of us grew up with – is a guiding principle of product development. If we can just listen to the customer – if we just give them what we want, our path to product success can’t be too far off.
Isn’t that customer obsession? Wasn’t Amazon where it needed to be? Well, no.
In fact, quite the opposite. Just blindly listening to customers is a surefire path to stay mediocre, or worse. It holds you hostage, forcing you to follow through on these blind promises you’ve made and, if you succeed, you end up with a bloated product. If you fail… well, goodbye trust.
Using open feedback systems, driven by customer desire, is not customer obsession. It’s customer abdication, and it holds you back from being clear-eyed about the decisions you will eventually make when doing customer development. Here is why:
The Ferrari Problem – customers want eye candy and aren’t thinking about how you’ll need to maintain it, or if it matters.
Customers have no context – they don’t know their market and live in a completely different world than you do.
Maintenance – systems which are open-to and guided-by customer feedback tend to need high maintenance to keep them useful. What tradeoffs are you willing to make to add confidence to the system?
Let’s explore these problems in-depth, and talk about how to avoid these problems with tools and concepts that are more likely to bring you better outcomes for your product development.
Vroom Vroom, I Want a Ferrari
If I offered you a Ferrari, would you take it? Sure you would.
Now let’s talk about maintaining the car.
Your oil changes are now specialized and cost 10 to 20x what they cost now
Any part is now specialized and you’ll need to find a specific mechanic with a smaller margin of error
Good luck finding the right gas station
Did any of this come to mind during the offer? My guess is: no, it doesn’t. My bet is even if you got a Ferrari, you wouldn’t use it. This is what I call the Ferrari problem – when we, as human beings, consider only the “thing” we’re acquiring, and not anything around it.
Your customers are human beings. I repeat, they are human. They will spend time telling you about how much they want a feature… and then they’ll never use it. They just wanted it because they thought it’s cool.
How do you avoid this?
Focus on the problems – customers are well aware of the problems they need solved. They are your best source.
Contextless Customers
You are probably looking at this on a phone or laptop. If I asked you about the microchip market, you might be able to answer. Let’s ask a few more questions:
How about the supply chain?
What about the other choices on the market?
How about any of the trade-offs necessary to ship this device?
I don’t expect you to be able to answer these questions unless you are a product manager from a company like Lenovo or Apple, and work in their hardware division.
You are a customer.
Now think about your company – my guess is that you are able to answer these questions pretty easily, but your customers can’t. Every time a customer requests something, they don’t ever have this context in mind. In fact, they are just thinking about the problem.
Instead of just expecting them to tell you what they want, ask them about the world around them. Ask them to tell you stories about how they interact with the product.
Open System, Open Problems
I once built a Content Management System (CMS) when I was younger (I am aging myself 😉) and, to my surprise, it worked. The little marvel allowed me to start my first company, The Gamer Studio, and bring on writers to start publishing content.
So I opened it up to feedback and feature requests, provisioned some usernames and passwords and I thought I was on my way… until it happened.
The first incident about corrupted data. Then the next, and suddenly it was a hack here, a hack there. For all the my openness to user feedback and feature requests had been well intentioned – after all, I just wanted to build the best product for my users – the reality was that it had led me down a path of feature bloat, technical debt, and a code-base that I had no hope of maintaining.
I eventually had to shelve it and do the hard work of manually transferring everything to Typepad. Sure, I made a system and opened it up to customer feedback, but I didn’t consider the maintenance costs I was also opening myself up to. I often see the same thing whenever a product team starts using a live “customer voting platform”.
These are open to all types of influences that run counter to your goal – for example, what happens when there is a voting “brigade” being led a single customer with a disproportionate amount of influence? Or a particularly nefarious competitor looking to skew your insights and roadmap?
Not only that, but you also fall into the trap of other parties, both external and internally, deciding your priorities based on bad or irrelevant metrics. For example, stakeholders in other teams or organisations using non-significant (or even, strictly speaking, irrelevant) vote counts to push an agenda. A CEO running a meeting and saying “It’s the top-rated feature request” when it has 17 votes has a particular sting to it.
Instead of voting on features, if you need to have customers vote on anything, let them vote and comment on problems. Put this at the beginning of your discovery process to help shape your research.
The Theme Remains: Focus on Problems.
Customers are a fantastic resource to understand (valuable) problems. However, defining solutions is where we run into more troublesome problems.
Take the solutions out of your customers’ hands, and give that responsibility back to your team.
This is a serious question and one you should be asking yourself regarding documentation.
As product people, we act as the keepers of documentation throughout every stage of the product development process. We didn’t ask for the role, but since product’s principal job is to foster alignment, it’s in every product manager’s best interest to advocate for best practices surrounding documentation.
Documentation is one of the best tools for maintaining long-term alignment and serves as a heuristic to see how the team’s communication holds up. It is one of the few artifacts that weaves its way through the entire product development cycle — even before a single line of code is written. And after a product ships, it becomes critical for engineers and customer support teams.
The perils of poor documentation
Without documentation, our teams end up making decisions that aren’t aligned. While this might not affect the product today, you can rest assured that you’ll lose a lot of sleep trying to get them back on track tomorrow.
Those of us who have been around long enough have a story or two in which great documentation saved a launch, a product, or even a company. On the flip side, there are plenty of stories where a few sentences would have saved weeks or even months of work.
Unfortunately, documentation isn’t sexy. Although it mitigates disaster, it does so quietly. As a result, it’s easy to forget about documentation or even complain that it is “useless.”As a mentor once told me, “No one loves the janitor, even though they prevent catastrophe since it happens in the background.”
One day, it will be 3:00 a.m. and the world will be watching. In that moment, you’ll want your documentation to be well-organized and useful. That’s what documentation is — a friendly helper in a time of need.
So, why is it hard to get anyone to read it?
Well, since it isn’t sexy, we rarely take the time to give it the care it needs. We end up with documentation that is fragmented, inaccessible, and ad-hoc. In a crisis, these are the worst traits for documentation to have.
As good product managers, we need to change that for the long term health of our products, and we can do that through the lens of visibility, accessibility, and systemization (VAS).
What is good documentation anyway?
We can’t talk about documentation without being clear about what good documentation is. This is where the VAS acronym comes into play. Good documentation is:
Visible. You can see an answer when you need an answer.
Accessible. You are able to get to more information quickly and easily.
Systemic. Your documentation is always improving within your work system.
Good documentation is visible
Where is your documentation?
When people are looking at documentation, they are usually in the middle of an anxious moment. This is the wrong time for anyone to be wondering where something is.
With documentation, the answer needs to be first, in multiple places, and shouldn’t require any thought on the person looking it up. Speaking of looking things up, good documentation relies on different ways of making information visible. Images, videos, indexes, and tables of contents are all useful tools to help the reader find their answer faster.
Talk to your team about how they like information to be presented, then organize that information in a way that they can understand. In fact, talk to them about your documentation itself and why it’s important. Remember that documentation is for all types of people, so you should be prepared for different styles and preferences.
Good documentation is accessible
However, being visible isn’t enough. Folks should be able to get to it, too
There is nothing worse than documentation that is hidden, or even worse, password-protected. Open up your documentation. That’s the easiest way to make it more accessible.
Once you do that, audit your documentation so that anyone that works at your company can read it. As Nielsen tells us, documentation needs to be plain. No codes, no esoteric messages — just plain language. You never know who might need to rely on that documentation in a pinch.
Make it easily searchable. Anyone who wants to read about anything should be able to access it intracompany — full stop.
If the path to help isn’t clear for the level of information, then everyone loses, and your documentation doesn’t serve its purpose.
Good documentation is systemic
Sure, it’s great that people can access your documentation, but how do we improve it? Do you think about documentation through the product development process, or is it something that is tacked on at the end?
If the answer is the latter, it shouldn’t be. Your documentation should iterate just like your product. I don’t just mean slapping a changelog on top of your documentation. Whenever you are looking at a feature or product, take a moment with the rest of your team to decide what is useful and what isn’t.
This sounds like a lot and can be whenever you do it for the first time. However, when it happens in every sprint, you’ll see it can be done in as little as an hour.
Your documentation should have milestones, no different than anything else in your app.
Documentation is critical
Your documentation functions as a great janitor. At its best, documentation serves as a way to save time and mitigate risk by giving folks an asynchronous method to get the answers they need.
Good documentation matters because both the team and your customers will need you when you aren’t around. However, this won’t matter if it isn’t visible, accessible, or built into your system of product development. And as a result, you’ll see other levers utilized (customer support or cancellation) for issues that are solvable through documentation.
If I asked you about your relationship with your customer success team, what would you say?
Whenever I ask product teams this question, I’m generally surprised by the answer: that there isn’t one. And if there is, it’s barely hanging on. Often, the relationship is very back and forth, with CS handing off customer problems — or even worse, solutions — to the product team. Then the product team places them either very high (bug or critical error) or low (enhancement) in the queue because they originated outside of the typical product development process.
This breeds resentment and the two teams rarely address it. The status quo remains unchanged and the opportunity for better alignment and communication is lost.
Does this sound familiar?
As a product executive and consultant with over ten years of experience, the customer success team is often the first team I talk to when trying to understand a business and its customer base. When the relationship between CS and product works well, important customer information, including qualitative feedback, feature requests, and emotional reactions to the roadmap, makes its way to the product team to inform their strategy.
Ultimately, a strong relationship with your colleagues in CS will give you a much higher success rate when launching products. And all of this for free.
How do you build such an alliance? Well, I put the onus on us, the product team, to manage the relationship and bring out the best in the teams around us. Product isn’t just a translation service — it also is a diplomatic one.
Here are three ways you can repair and improve that relationship with your customer success team:
Hear them out
Bring them into the research process
Be transparent
Hear them out
Typically, your customer success team is going to be the lowest paid and the least listened-to team in the building. Their job is often a taxing one — customers frequently yell at them, and they work on the front lines of frustration, listening to customers vent at their lowest moments of using the product.
Your job as a product leader is to take the opportunity to sit down with them and listen to what they have to say. If the relationship I described before sounds familiar, they will likely have a lot to say.
How should you frame this conversation? I’m a big fan of the team retro process laid out by NOBL here. A team retro gives you and that team at least 60 minutes to get things completely on the table. Remember, the retro process isn’t about blame; it’s about level-setting and improving, so make sure you use that time to get a clear lay of the land. Both teams more than likely have some misconceptions about the work the other does. It’s finally time to clear them up.
Bring them into the research/product development process
I think the biggest distinction that the product team should communicate with the CS team is that they have a good understanding of the emotional state of reactive customers, but aren’t always clear about the problem set of proactive customers. That is the difference between research and inbound. Making that distinction clear with your customer success team is the start of engaging them with the product development side of the house, instead of “break/fix.”
Something as simple as inviting your customer success team to the research outlines and asking them about common customer frustrations can give you a world of information — not just about what the customer wants, but opportunities to get help, even in the way they process inbound.
Also, make sure each product team has a customer success advocate on board. They don’t have to go to every meeting or engage in every conversation, but it helps keep the team involved and may lead to useful insights when the build begins.
Be transparent
You’ve already built some serious inroads if you’ve been doing the above two methods regularly. The next step is to be transparent. This involves a potentially big change in your product strategy: inviting the customer success team in to talk about it.
New hires coming in to shake things up? Let the customer success team know. Doing some sort of tech debt initiative and new features are temporarily suspended? Bring them on board. Keeping the customer success team aware of all the big movements from your perspective will build trust and help mend any damaged fences.
Remember to continue to do the retro as well. Once isn’t good enough — make it a regular occurrence to encourage consistent engagement and communication.
Customer success and product can work well together
Our customer success teams are on the front lines keeping things running smoothly every day. We have an opportunity to use that expertise to make better decisions about the products we bring to market, and how our product development serves customers. The way we get there is by making sure that we stay open, bring them along, and continue to build trust through transparency.
Building the right products is a team effort, and when we all work together, great things happen.
It’s the most dubious phrase that comes from our teams.
Why?
Because if they have enough pull, we can spend hours building an idea that makes sense to that person, or even internally, and do nothing to the marketplace.
I’ve seen it a ton of times in my career, someone swears they have a genius project, and bang, soon enough there is 300 hours into something that has a 2% usage rate.
Uh oh, and back to the drawing board.
As marketers, it is our job to understand the market and in some respects, save our teams from making the mistake of building what they swear is right when the market will eat it and spit it out.
That is where no code MVPs make sense.
Today, we are going to talk about what No Code MVPs are, how do you leverage them in the wild, and how to talk to teams to make sure you get to use it first.
What is a no-code MVP?
There are three things to consider when talking about a no-code MVP:
No-Code means no code. You won’t be going to your engineers to build this thing, and to most folks, that is a huge win. You get to maintain control, learn more about your customers, and if successful, get some of the marketing out of the way before the feature launches.
MVP is Minimum Viable Product – a LEAN concept that means the smallest thing you can get out the door. Some folks may quibble about what “viable” means in this context, however, the thing to take away here is that we are really trying to understand the viability of our hypothesis.
Your hypothesis is what you want to learn. Everything you build should have a falsifiable hypothesis. This is important because you need to know when to move on.
Put them together, and you have a No-Code MVP.
Now, you need to build something that allows you to test your hypothesis. The simplest way I’ve seen this done is a landing page. These days, it seems like all email service providers have internal landing page creators, so pick yours and rock and roll.
The writing on the landing page, as well as any supporting documentation and materials (I like to write a fake blog post to help get my thoughts down) should focus on the hypothesis.
Leveraging the no-code MVP
Now, we’ve built something that collects emails. Who should we send them to?
It depends on your appetite for risk. If you like a controlled population, look at your “beta” users – these are folks that you or your team has already predetermined enjoy the cutting edge features. Set a success rate and go for it.
If you don’t have a population set aside, or you don’t mind spending some money, you can leverage Facebook.
Facebook has some great tools to create lookalike audiences, and if you are comfortable with them having that data, you can extract your customer list to build a lookalike audience that excludes your current customers. This method may be good if the something new is completely different than your current offering.
Now, it’s time to play the waiting game.
If you have success metrics set up, after a set amount of time, see if they match up. If they don’t you can feel comfortable that this isn’t something they want.
Now that you have the data you need, you’ll need to present to the team.
Talk to your stakeholders, present the data, and if this is the first time you’ve done this, take the time to tell them about the process.
Remember the why – your no-code MVP is designed to save other teams time and get them back to working on things that are impactful.
You’ll have plenty of data, from potential polling to quotes to help make a decision on whether to move on. Use it to sell your case to those stakeholders.
No Code is the Way To Go
With enough time in tech, you’ve sat in a room with a team that had a similar experience to thought exercise that led this article.
I haven’t met a professional yet that doesn’t like to have everything they work on sit on a shelf. No one likes to waste the money, momentum, and more importantly time it takes to get something out the door.
Leverage that No Code MVP to save your company time and money, and as a bonus, build some trust along the way.
