Ronke Majekodunmi – How to build strong coalitions
Tonya Edmonds – How to Successfull
Vince Aidoo – The Value of Learning from Failure
Ayo Omojola – Fighting Covid and Pushin
Rafael Balbi Jr. – Key Learnings in Becoming a Principal PM
Sasha Kai Parker – Incorporating Innovation into Product
The process is performed to define a problem, explore potential solutions and build a working prototype that will present value to customers. Modern product discovery and validation is essential to startup success, for example, those utilizing the outcome-driven innovation framework see an average product success rate of 86 percent.
Product discovery is typically undertaken by diverse teams of stakeholders from throughout an organization, such as product teams, UI/UX researchers, data analysts, product designers, executives and others who are closely aligned with customer needs and insights. This helps create a link between the customers and the business before any work is done, ensuring that the intended product will be useful and not fail due to a lack of adoption and users.
The roots of modern intentional product discovery and validation can be traced back to the 1990s, when Steve Blank created the customer development philosophy and published the book, The Four Steps to the Epiphany: Successful Strategies for Products that Win. Eventually, Blank’s methodology facilitated the start of the lean startup movement where customer development is considered a main pillar. Simultaneously, Anthony Ulwick developed CD-MAP, which would eventually set the course for the creation of outcome-driven innovation and the jobs-to-be-done theory.
When conducting product discovery, it is first important to ensure that empirical user research is done so qualitative and quantitative data can be gathered. This allows discovery teams to challenge their own assumptions about what a user needs and gather data on potential product use cases and customer pain points. From there, teams can form design artifacts that allow the data to stay top of mind and be easily referred back to throughout the discovery and development process. These artifacts often include journey maps, empathy maps and consumer personas.
Journey maps are a set of actions that the user is expected to take to achieve their goal. The actions taken are marked as “locations,” and the product is expected to reduce the amount of actions needed to accomplish the goal. Journey maps must be based on empirical user research to accurately determine what the product will accomplish. Empathy maps are a four-quadrant diagram that are used to record what customers think, hear, say and see in regards to their challenges and the product’s opportunities to present a solution. This helps companies understand user feelings on products and services. Consumer personas are an approximated segment of users that come to be known as target customers. Personas are named and matched with demographics, psychographics and behaviors that help identify a potential customer.
Product discovery is all about identifying solutions to customer challenges. By doing so, companies seek to build products that provide continuous value to both the user and the business. This requires risks to be clearly identified before teams can begin building a prototype. These risks include: value risk, or whether customers will adopt the product; usability risk, or whether users will know how to utilize the product; feasibility risk, or whether it is capable to produce a product with the allotted time and resources; and business viability risk, or whether the solution will also work for other aspects of a business.
Once these risks are identified, stakeholders have a better understanding of user needs and can create an optimal solution through ideation, prototyping and testing processes.
What kind of relationship do you have with your company’s customer success team? I often ask product teams this question, and the answer is usually that there isn’t a relationship at all. And if there is, it’s hanging on by a thread. The product team never connects with the customer success team except when it’s time for an “enablement” session. The session is designed to allow other teams to understand a product. This meeting, though, is likely to just be a quiet presentation and Q&A.
Meanwhile, the customer success team tends to see the product team as the product feature repository. They just drop off feature requests and then go back to their own work.
Both forms of communication are reactive. Customer success hands off customer problems with solutions and dates to the product team. The product team uses customer success as a shield against the customers themselves. Neither team leverages what the other knows to maximize their ability to collaborate on solving big customer problems and innovating in the marketplace.
But that dysfunction isn’t the most significant issue. The organization is building a culture of resentment. The teams will continue to resent one another until something changes. So, they’re losing in two ways. They lose the opportunity to leverage the intelligence of both teams, and, because of the resentment, the business misses out on some moonshots that could change its overall trajectory.
Before we talk about the tactics we can use to make things better, we first need to address that resentment. Remember, it’s the product manager’s (PdM) job to increase the overall decision fitness of the organization. By decision fitness, I simply mean how well the team makes decisions. Good product management leads teams to consistently make better decisions. You won’t be able to level up in this area if there are no clear lines of communication between customer support and product.
So, let’s talk about how you can identify some of the issues both teams have with each other, create more precise lines of communication, and tie it all to your culture so that it stands the test of time.
Your customer success team is likely the lowest paid and the least listened to team in the building. Their job is often a taxing one. It’s a matter of when and not if customers are going to yell at them. The customer success agent is on the front lines of frustration, listening to customers vent during 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 poor relationship between teams that I described before sounds familiar, they will likely have a lot of valuable information to tell you.
Let’s set the stage with BobCo, where two leaders, Jill, the new director of product management, and Bob, the new director of customer success, are connecting for the first time. They plan to get the company on a better path and leverage each other’s team for better product outcomes.
Bob and Jill both took the time to listen to their teams for the first 90 days of their tenure. They also talked to other disciplines, like engineering and sales, to get a solid overview of the organization.
Both connected with a random distribution of people, taking advantage of their newness to the organization, and led one-on-one conversations with everyone on each team around three subjects.
Bob and Jill both know that the secret to identifying issues is to build trust. That trust must first start with themselves, so Bob and Jill spend time listening to each other and developing a shared vision of their futures.
They spend their first few conversations feeling each other out. Once they get to know each other a bit, they agree that a team conversation will give them a jump-start on understanding how product and customer success can work together.
How should they frame this conversation between the two teams? I’m a big fan of the team retro process laid out by NOBL.
A team retro gives the facilitator and the relevant team at least 60 minutes to get everything out on the table. Remember, the retro process isn’t about blame; it’s about level-setting and improving, so make sure you use your time together to get a clear lay of the land. In our example, both teams more than likely have some misconceptions about the work the other does. It’s finally time to clear them all up.
Both Bob and Jill are coming into teams that already exist. Like most of us, they have to deal with the culture that’s already there. In this case, it’s one that is marked by the resentment that I mentioned earlier.
Without presenting a solid foundation to both teams, one that establishes competence and tells a story that people can trust, and showing that they trust one another, they know this process can fall apart.
A team retrospective can raise issues that plague teams and businesses. Both leaders are committed to handling the pressing problems upfront, by writing them down and following up. They present regular status updates to ensure that no one had to work to find out what was happening. They also keep each other accountable by holding routine check-ins. All of these steps can go a long way to establishing trust.
So, you’ve done the first team retrospective. Put the next one on the calendar in about a month. Keep this meeting a consistent part of both teams’ workflow. Every time each team talks, you’ll build more trust. But you’re not done there.
After the retro, Bob and Jill realize that just talking about the issues won’t be enough. Instead, they need to change how the teams communicate. This change means moving from a reactive approach (enablement and feature requests) to a more proactive one. Making this shift requires bringing both teams into regular contact during product development.
So, they pick one point during a sprint for the customer success team to meet with the entire product team to talk about development and see how customers may engage with the product as it’s being constructed.
This connection point helps the customer success team understand how to talk about the product with customers and get their insights. Because they now know how to frame these insights, the product team is more likely to receive this feedback instead of brushing it aside.
And this new structure leads to an important point. Customer success teams have a good understanding of the emotional state of reactive customers but aren’t always clear about the problem set of proactive customers.
Bringing the customer success team inside the process allows them to guide the product team in addressing the customers’ emotional needs as it’s building the product. For example, say you have a section of customers that are angry about your latest widget. The customer success team can take a look at the next iteration of the widget and tell you exactly what they are hearing, which will help the product development team avoid potential landmines.
Jill knows by bringing Bob and his team around in the middle of the process, the team can make sure they solve more pain points and build a better story to present to the customer. Bob knows by bringing Jill around, his team can frame customer requests more effectively.
Keep in mind that the PdM should under no circumstances consider this feedback qualitative research, however. The customer success team’s involvement isn’t a replacement for talking to customers. But it is a great way to make sure each team is making the most of one another’s expertise.
Bob and Jill know that working together will lead to stronger teams, but they need to make sure they can keep it that way. After all, these are two teams that have had some contention before. Bob and Jill need to keep the newfound trust going.
The continuing retrospectives will help to identify any trouble between the teams as it happens. This relationship isn’t going to work like before, though, and change is fragile. So, leaders will have to talk often about both successes and failures. Transparency is the bedrock upon which you build trust.
You’ve already made some serious inroads if you’ve adopted the retros and invited customer success into the development process. The next step is to instill a culture of transparency.
Bob and Jill set up a report designed for the business; they call it the BobCo Product to Customer Report. Inside, they highlight anecdotes from customers and how the different product development teams are each building products that meet the needs of the customer. Those anecdotes fit the story the product team is trying to tell, and speak to how those customers will be affected by the change. They also include data about research, renewals, churn and team changes.
Are new hires coming in to shake things up? Is the team doing some tech debt initiatives that mean new features can’t happen right now? Are you holding office hours? All that information should go into the report. This report then goes to the rest of the business to build trust and allow them to keep an eye on the product strategy.
MORE IN PRODUCT MANAGEMENTWhat to Do When Product Theory Isn’t Your Product Reality
Customer success and product can work well together. What does it look like when it works?
Important customer information gets back to the product team and influences strategy. Remember, product management’s job is to improve decision fitness. By taking in the emotional energy of the customer, we can better understand their points of view, leading to better decisions. Customers aren’t acting out. Their feelings come from somewhere. Customer success holds the key to understanding where.
A strong relationship with your colleagues in CS will give you a much higher success rate when launching products.
How do you build such an alliance? I put the onus on 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. We’re here to build bridges to help us level up the decision fitness of the company as a whole.
Our customer success teams are on the front lines keeping things running 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. We get there by making sure that we stay open, bringing them along, and continuing to build trust through transparency.
Building the right products is a team effort, and when we all work together, great things happen.
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:
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.
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.
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…
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…
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.
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.
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.
“I have an idea.”
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.
There are three things to consider when talking about a no-code MVP:
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.
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.
If they do, now it’s time to talk to these customers. Don’t know how? Well, I have another article for that right here that will help guide you.
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.
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.