Agile is GREAT, but…

Agile is great, but…

Agile is awesome. Nearly every Product Manager we know would agree. But I bet you’d be surprised by how many conversations we have with product leaders around their questions, issues and sometimes not-so-stellar experience with agile development. Questions & comments like:

  • Our product managers/owners feel constantly overwhelmed working day-day with dev, we have no time for innovation!
  • Anyone else have confusion over roles within their agile teams, or is it just us?
  • How are others dealing with technical debt, our seems to just keep growing…
  • Do you need to have both product managers and product owners?
  • We can’t expect our product owners to also be strategic…can we?

Agile is so clear about roles, and ceremonies. Backlogs are groomed continuously to focus on the highest priority. Customer Value is built right into the manifesto. So, why are there so many “we love agile, but…” conversations in the product management community. What’s going wrong? We have a hypothesis on why this is happening, and a proposal for a universal fix across all agile teams. Let’s start with three assumptions that we have about how we believe products should be built.

  1. Before you build…You know what is important to customers. There’s a loaded sentence. We built an entire business helping companies get this right. Anyone can create epics and sets of user stories — that’s easy. That’s how exploding backlogs happen. Because it’s just so easy to create work, and agile is a well-oiled machine designed to keep churning out work in tidy increments. But, as we all know, outcomes aren’t equal to effort. And meaningful business outcomes are those that prove we’re providing value — because customers buy and continue to invest in the products we deliver. All that comes from deeply understanding your customer.
  2. Before you build…You can define the customer problem. That doesn’t mean being able to describe all the incredible features you’re building. It does mean being able to state the customer problem that exists, independent of your product ever being launched in the world. That means, there are lots of ways to potentially solve the problem, but you (team, company), are uniquely positioned to deliver a solution that will win in the market. And btw, the problem should be a big enough pain that the customer is willing to pay to make it go away. When you can do this, you know you’ve got an important problem to solve.
  3. Before you build…You have a vision and a roadmap. A roadmap is not a rolling collection of features — it’s a clear, well-thought out, logical and prioritized map to achieve a vision. Having a vision is what allows you to make tough trade-off decisions, and it’s what keeps the team (and you) energized and motivated to make it happen through all the ups & downs of development. Having a vision starts with #1 & #2 above — knowing what’s important to the customer and what problem you’re solving.

If you buy into these assumptions — then let’s talk about how you can leverage them to make a big impact on how well agile can work for you. This is based on years of experience working as a product leader with with dozens of agile teams, and from our coaching practice improving the ways that product managers and product owners can succeed working within agile development.

You have to know where you’re going. Remember the bad old days of waterfall development? If you don’t, lucky you! For those of you who shuddered when we asked the question — you had flashbacks of writing massive requirements documents. But, the one (and maybe only) good thing was that it forced you to think about where you were going. You had to think about the big picture before you could break it down to endless requirements and (depressingly) writing down every possible exception. We’re not suggesting for a second we go back to the dark ages. However, what we’ve missed in our head-first dive into agile is providing the team with the big picture in a way that’s meaningful. That doesn’t mean one flashy PowerPoint slide of a vision, or some high-level product mockups which makes your CEO happy. We’re talking about providing a real schematic that offers a picture of where you’re going, and enough details that allow the teams working with you to ask great questions, offer alternatives and help improve the overall solution.

Let’s say you were giving the job of building a house, your first step probably wouldn’t have been to assemble a building crew, and say to the foreperson — we’re going to get started and build a room at a time. Let’s see where end up! Before you had a team start to pour concrete, or put up framing, you would have worked with an architect to create a plan. The inputs to that plan are customer needs. Imagine a home for a young couple, mobile, working from home, wants amenities/access such as pool/gym…and then think about a family with 4 kids, one member is in a wheel-chair, they entertain a lot, generally home-bodies. Very different needs, very different home. Your understanding of how the home would be used, the people who live inside, what they would do within their home — all of these are critical elements in understanding the type of building we’d create. We don’t expect a building crew to start building without a plan — and the opportunity to ask questions, and maybe suggest some changes that would make it cheaper to build, or offer additional value elements for the same price. Because they understand what you’re asking them to build — they can have a voice.

The same is true for a product — we need a picture of our customer, what she cares about, her habits and attitudes — and through understanding this, we enable our teams to imagine a real person that we’re building our product for. A product manager’s job is to provide this picture. Agile wants you to know these things -it really does. It just doesn’t give you any time to make it happen. If you forgive agile for not building in a ceremony just for product management, then it changes the way you will look at your development cycle. The way to coach teams to provide this critical information is to develop and share a Product Scope. A Product Scope gives the schematic, the plan for what you’re planning to build, it provides a picture to the team so they can imagine it. They can then connect with you on the plumbing, the electrics, they may even suggest shifting rooms around, or describing a completely different approach which you never imagined. This will happen because you have everyone on the same page, then…you can begin Sprint 0, start planning and happily create epics and write user stories. You all know where you’re going.

Having a Product Scope will change your experience with Agile

We’ll talk more about how to create a Product Scope in a follow-up post and the product work needed before sprint planning. We’ll give you a hint — writing kick-ass Product Scope documents comes from deep customer understanding, which starts with setting up hypothesis, ideating, prototyping, testing — all with customers.

Before we close, just a couple of extra agile tips for kicks. Spikes are not your friend. A lot of the time, we see customer research being placed on a sprint plan as “research spikes”. A spike, technically is something that is not clear to the team, or can’t be estimated well. The whole purpose is to provide an answer or solution so that the team can get going again. Assigning points to research is meaningless — your entire product success rests on your ability to learn from your customers and build that into every sprint. That’s right — you should be learning from your customer EVERY sprint. That doesn’t mean fitting them into research spikes. btw, spikes aren’t great for the team either, it impacts velocity and timelines and all the things your scrum master cares about. Don’t use them.

Build in Time to Watch Customers. Technically this isn’t an actual way to make agile work for you, but it’s just the very best gift you can give your team. It works whatever development method you’re using. It will change the way your team work. We suggest at the very minimum once a quarter, you should provide a way for your team to spend time watching customers. It will dramatically change the customer value your team delivers.

What other agile and product management tips do you have? Share your comments and thoughts.

Skills of Product Leaders Required in Unprecedented Times (Part I)

COVID-19 has changed us all in irreversible ways.  On a personal level, I don’t think any of us will ever be the same.  On a business level, if we are still lucky enough to be employed, the interrelated effects are numerous. As leaders we are trying to keep our employees and customers safe, re-orienting our day to day operations to a virtual norm, and navigating our way through the unknown to keep our businesses on solid ground, let alone driving growth.

Vidya spoke about making product decisions in crisis mode a couple weeks back which was really helpful.  I’m going to take a different look at this.  Focusing more on the skills of product leaders that are required to address some of the categories of product impact resulting from COVID-19.

Beyond the obvious impacts of COVID-19 we’re finding that the product impacts are exposing skills gaps among PM leaders and product managers alike.  Today I’m going to focus on the required skills of PM leaders in addressing the broad categories of impact COVID-19 is having on businesses. 

All businesses have been impacted in some way, but we see a few broad themes of impact to businesses that kick the product management function into a relatively higher gear.

ImpactExamples
Irrelevant ProductAirBnB, Hotels
Irrelevant Business ModelNon-essential Retail, Gyms, Theme Parks
HypergrowthZoom, Doordash

Today I’ll talk about the irrelevancy related impacts. 

Well talk about hypergrowth in a subsequent blog post. 

What does irrelevancy mean? 

  • Product irrelevancy is probably the most challenging.  The problem you were solving no longer exists. AirBnB is an example we’ll talk about later.  This could be temporary until normalcy is regained.  If you do nothing, it’s a race between your cash on hand and the return to operational and income normalcy.  
  • Business model irrelevancy is when the channels and ways you are selling your products/services aren’t relevant, even if your products/services are still desired or needed.  It’s more of an opportunity than product irrelevancy if the costs to change the ways in which you offer your product are not prohibitive.  And if you can do this quickly and can regain some of the lost revenue, it dramatically slows the race down until a new norm can be established.

Irrelevancy is a situation that we all may find ourselves in at some point in our career due to the common product lifecycle.  There is a launch period, a period of rapid growth, and established period, and decay.  Decay usually means that your product or business model is becoming irrelevant in some way.  Most tenured product leaders have gone through each of these periods at some point in their career.  With COVID-19, some of us are going from any one of the early stages into decay (or irrelevancy) within days versus what we usually see in months or even years.  This leaves some leaders exposed if they haven’t flexed those muscles in a while, if at all.   

You wouldn’t be a product leader had you not excelled in the basics.  So I’m not going to rattle off a bunch of standard leadership principles.  However, there are a few skills/practices that are critical for product leaders in these clutch moments:

  • MOVE – Driving Through the Fog
  • CREATE – Seek new ideas
  • LEARN – Continuous scrappy research

MOVE – Driving through the Fog

In crisis, we see many leaders become paralyzed.  It’s scary.  This kind of impact, at this pace, is unprecedented.  We probably don’t have the data and it’s hard being comfortable making any decision or taking action in fear of making the wrong decision.  But…in these cases, no action means decisions get delayed and usually get taken over by opinion.  Teams spin their wheels for weeks or even months.  In these times, we don’t have the luxury unnecessary delays. 

“More is lost by indecision than wrong decision. Indecision is the thief of opportunity. It will steal you blind.”  -Marcus Tullius Cicero

Driving through the fog is the ability to define a product path in the midst of cloudy or complete lack of data, overwhelming competing opinions, and numerous ideas.  It’s defining that path in spite of this and getting commitment from the rest of the organization that matters.  We, as product leaders, make a path out of what seems like no path at all. 

It’s a lot easier when we’re not under duress like now. Let’s face it, these are unprecedented times for product leaders and the time we have to act is extreme.  Moreover, optimistic estimates show that a vaccine (or when things go back to some semblance of normal) will take a minimum of 18 months.  Again, optimistic.  But this means we need a path to survive (and even thrive) in this new (albeit somewhat temporary) norm.

So how do we drive in the fog in time of crisis? 

First, breath. 

Then act … Using these principles

Use Educated Hypotheses to Start:  We will never have all the data we need as fast as we need it.  In lieu of this, set hypotheses by leveraging what you do know. Use proxy data to help triangulate on hypotheses where possible.

 Some areas where hypotheses might be helpful:

  • Product Irrelevancy:
    • How has the problem your product is solving changed? Why?
    • How has your target persona changed?  Why?
    • Are there new problems your team might be able to solve?  Why?
    • Are there new markets your team might be able to address?  Why?
  • Business Model Irrelevancy:
    • How has the problem your product is solving changed? Why?
    • What part of the business model has been affected the most?  Why?

Establish some key hypotheses and build an action plan as though they were true.  In parallel, work on proving/disproving those hypotheses with scrappy research practices.  Well talk about this later.   

Build a simple plan:  Instead of building a list of product efforts, help people understand your logic, not just the actions you’re taking.  As you learn and prove/disprove your hypotheses, you will certainly update your course of action.  These updates can be confusing and disconcerting to people if they don’t understand your logic initially and what you’re learning that might be changing your course of action.  A simple plan outline that I often use:

  • Summarize what you know…Key data points and customer learnings that matter
  • Translate those data points into insights or hypotheses and what it means to the business.
  • Summarize what action and/or product path(s) should be taken as a result
  • Articulate next steps and who owns what

Pretty simple stuff, I realize.  But I often find, in a crisis. that leaders jump straight to actions without insight-driven logic beyond those actions.  Then the organizational churn begins….time, we don’t have, is wasted.

Communicate Early & Often:  Your teams need more communications, not less, during times of crisis.  And they don’t need “business as usual” or the “We will live on…” speech from the movie Independence Day.  They need confidence that their product leader has a logical plan forward (even if it might not be 100% right,) and will learn and pivot where necessary to get to the right product path.  The best product leaders (and even CEOs) I know, say things like…“We don’t have all the answers, but here’s what we do know and what we’re going to do about it.  And we’re going to learn as fast as we can along the way.”   

The other misstep I see is the lack of communicating what the team is learning and how it’s changing the original course of action.  In crisis, things can change daily as you learn more.  There is a high likelihood that you confuse people not close to the action and create unnecessary churn (there’s that word again.)  Through my own misstep here I have heard things like:

“I thought we were doing this?” 

“Why is product changing the plan again?”

“That doesn’t make sense?” 

“We should do this instead!” 

…All of which can be avoided by a regular interval of communicating what the product team is learning (Learning is progress!) and how it impacts your plan.  This provides the continuity people need and allows them to continue to see the path forward.  Remember you’re serving as the driver through this fog and your passengers need reassurance.

Tip:  Use the “simple plan” we discuss above; hopefully the one you presented at the beginning of this process.  Show what’s changed and the logic behind any change in your course of action. 

I could go on here.  There are a ton of books on crisis leadership.  But product leaders have a uniquely tough job.  Many CEOs expect us to lead the thinking on a product path in times of crisis.  We are expected to find a path quickly when there seems to be no path at all.  It’s navigating through this fog effectively that enables survival, if not success.

CREATE – Seeking New Ideas

Okay saying you need to innovate quickly is an understatement.  We usually think about innovation in terms of a multi-month, clearly-outlined processes including approvals, research studies, and experts.   That is not the innovation I’m talking about here. 

We need to facilitate extremely fast discovery and definition of big problems and the identification and testing of their solutions.  This takes some solid design thinking practices and a comfortability with speed.

Design thinking isn’t some super-secret set of rituals practiced by master designers at companies the likes of Apple or Tesla. 

I like the definition that the Interaction Design Foundation has for design thinking:

Design thinking is a non-linear, iterative process which seeks to understand users, challenge assumptions, redefine problems and create innovative solutions to prototype and test.

Wouldn’t we all say this is part of our job as product leader?  Can I get a ‘YUP?’

There are more than 1,000 design thinking methods out there.  All have their value.  The goal for us is to leverage the necessary methods in facilitating the following:

  • Definition of the problem and who you’re solving the problem for.  This could be redefining the problem you are already solving or the target market you have been focusing on.  It could also mean discovering a new problem or target market that has arisen out of this new norm with COVID-19.   
  • Ideating ways to solve the problem
  • Rapidly prototyping & testing your way to the most viable solution…turning prototypes within days not weeks.

Let’s look at AirBnB.  They experienced up to 80% declines in reservations in Europe and over 50% in some parts of the US; all within a few weeks.  They had to offer blanket cancelations for travelers, put their founders’ salaries on hold, and slash salaries of top executives by half.  They even set up a fund to compensate hosts for up to 25% of their lost income.  While this helped with regaining goodwill with hosts and travelers, the pressure is on to solve the bigger problem.  What do they do now if travel is impacted for years, not just these weeks while we’re in quarantine?  You could argue that their product is irrelevant or close to it as the perceived risk of the virus stays high. 

They mobilized and innovated quickly.  Within weeks they’ve been able to release two new product ideas.

Frontline Stays:  This is a program offering pandemic frontline healthcare workers a place to stay.  As the pandemic worsens healthcare workers are traveling to hotspots and need a place to stay.  Their continuous exposure is also presenting high risk to their families at home.  So AirBnB quickly moved to leverage the large base of unused inventory to solve the problem.  And while initially they offered the stays free, many healthcare organizations and government agencies are supporting the effort.  New big problem solved for a new market segment.

Online Experiences:  Debuting in mid April, 2020, AirBnB began offering Online Experiences.  Their travel Experiences offering was halted with the pandemic but they quickly identified another new problem to be solved; Recovering hosts’ income. They’re doing this by offering a platform for hosts to offer intimate, online cultural experiences through AirBnb. Online “tourists” can enjoy everything from discovering the rhythms of Puerto Rico to Cooking with a Moroccan Family.  These experiences range in price from a few dollars per person for an hour experience to $40 per person. 

Will these be successful?  Jury is still out.  That’s not the point.  The point is not that AirBnB has nailed the winning product decision, the point is that they are testing and learning quickly.  They launched both of these within weeks of the announcement of a pandemic.  It’s this continuous, rapid innovation that enables quicker recovery in times of crisis. 

LEARN – Continuous scrappy research

We tend to go heads down into problem solving mode immediately.  Action is good.  The goal is to take informed action wherever possible and as fast as possible.  That’s why we talk a lot of about scrappy research.  How do we define scrappy research?

A small number of structured customer or stakeholder interactions to test your most pressing hypotheses within 5 working days.

Vidya talked about scrappy research briefly a couple weeks ago in one of our blog posts. It’s one of the foundations we teach at Product Rebels.  Instead of going into all the tactics of scrappy research, let’s focus on one of the biggest challenges product leaders are facing in operationalizing scrappy research in this particular crisis.  They are not having the same access to customers and stakeholders as they once had and are struggling to get timely feedback as they are trying to move quickly.

And to add salt to this wound, many feel like they have to reach sample sizes of 50+ to be able to make decisions.  That’s a daunting task in the best of situations.

What we need to focus on here is enough to educate your hypotheses so that you can move forward.  Don’t worry, you’ll continue to test those hypotheses; this isn’t one and done.

Experts, like Nielson Norman Group, say that 5-7 interviews are enough to develop rough actionable themes.  Yes, only 5-7 interviews!!  After that you start to hear repetition.      

Feeling like scrappy research is more doable now?    

Here are some ideas on getting access to participants for your scrappy research:

  • Proxies:  There are two types of proxies.
    •  Internal:  Your sales teams, implementation teams, customer service teams and any other frontline employees can be great resources
    • External:  Many of us have partners and vendors that may have easier access to our customers.  VARs, distributors, eCommerce partners, etc.  Even if they were hit by this crisis, they hold different perspectives and potentially rich insights about your customer.  They may have an easier way to connect and may be open to partnering in gathering additional insights if it can help them as well.
  • Webinars:  There are a lot of companies turning to webinars and other online mediums to offer content and stay relevant.  It’s also a great way to learn.  Work with your marketing team in creating ways during those webinars for your customers to offer feedback and insights.  There are some great tools out there for polling, questionnaires, etc. during presentations.  Don’t miss this touchpoint to learn.
  • Virtual “Focus Groups”: Okay, not a fan of focus groups, but we gotta do what we gotta do in these times.  Similar to webinars that you might already be doing, can you test less-formal ways to get your targeted customers on a virtual call to gather feedback?  Is there value in bringing customers together to share challenges and best practices in dealing with the crisis?  What are ways you can bring people together and learn online while adding value?
  • Social Media & Other Digital Gathering Points: Most companies have social media or other digital channels where customers will post issues, questions, bugs, etc.  Can you use polls, questionnaires, or just posts to gather feedback?  Again, can you partner with your marketing team and other operational teams to field questions in the current touchpoints or channels you are already in?
  • Surveys:  Let’s be clear, surveys are great for quant views at the market but not totally actionable beyond sizing or high-level trends.  That’s because we don’t get the “why” behind any given answer.  The “Why” is where we can define the problem and take action from a product perspective.  But in times like these, surveys may be all we got.  Using open-ended questions may get you to some educated starter hypotheses where no other data exists.  Surveys are also great for finding people that are open to chat more.  Asking the question “Would you be willing to spend a few minutes with us so we can learn more about your answers?” helps you quickly identify folks you can talk to.
  • Recruiter: Recruiters are expensive, no doubt.  An average cost for finding one recruit is $135+ and higher for the more niche profiles.  But a lot of recruiters are fully digital using phone and survey methods to recruit.  If you have the budget, recruiters can be a saving grace. 

The point here is to help your teams get creative in getting access to customer insights as quickly as possible and in sustainable ways.  If you have other ideas on ways to do this, please share with your fellow product people below! 

In summary, product leaders are under some serious stress right now.  The buck stops here when it comes to defining the product path to get through these unprecedented times, especially in rapid, even if somewhat temporary, irrelevancy situations.  It takes a few very special skills to get through this.  It’s the ability to find and communicate a logical path where no path seems to exist, the ability to practice extremely rapid innovation, and have your entire team continuously learning and informing that innovation that will enable the best chance for company survival when your product or business model has abruptly become irrelevant.

Are you a product leader Interested in talking about this more?  Our next Product Rebels forum on May 8 at 10:00am PST we will discuss these skills and answer any questions or challenges you are having.  Get the deets by Joining our Product Rebels Community on Facebook

Product Rebels is a product management training and coaching firm run by long term product executives for companies like Intuit and Mitchell International. We have trained over 200 companies small and enterprise level in the skills and frameworks that help product management leaders and product managers deliver kick-ass customer experiences.    We have a passion for finding efficient ways of infusing customer insight into everything product teams do in pursuit of experiences that customers love …that drive growth.  Join us in the Product Rebels Community on Facebook or the Product Rebels Community on LinkedIn.

Take a look at our very practical training courses and coaching programs that give you practical tools, frameworks, and support you can use tomorrow in becoming a more effective product leader.  www.productrebels.com

And stay tuned for our new book.  Sign up for updates on our new book “Groundwork. Get Better at Making Better Products”

4 Lesser Known Traits of Successful PM’s

During this pandemic, I’m reading a lot about the tough situations people are in in terms of losing their job. Many have decide to move into PM from other functions like dev, UX, customer support, and business analyst roles and are asking for advice on what they can do to make themselves and their resumes more marketable in the PM space.

I felt compelled to offer up some thoughts on what it takes to be a successful product manager. These aren’t just for those transitioning to PM…they’re skills and behaviors that are critical whether you are new to the function or polishing up your skills during the downtime this pandemic has forced upon us.

Much of the advice I see in the communities I’m engaged in center around the ability to gather requirements, ability to understand technology, domain expertise, strategic thinking, analytics, communication skills, and time management. All good skills to have in most functions within a company, don’t you think? I mean, I should be strategic, analytical, manage my time, know my business space, etc. as a development leader or an ops leader.

The point is, I see a lot of very high level, generic skills being thrown out there for product managers. And yes, they are all good skills to have. But I like to focus on the skills that a lot of PM training and books don’t cover.

Below are 4 behaviors/traits that you probably don’t hear as much about that are just as critical, if not more, to your success, long term. I’ve also added tips on what you can do today to begin building muscle in each one of these.

Empathy.

Merriam-Webster defines empathy as:

“the action of understanding, being aware of, being sensitive to, and vicariously experiencing the feelings, thoughts, and experience of another of either the past or present without having the feelings, thoughts, and experience fully communicated in an objectively explicit manner”

You probably have heard of this one. If you’re a seasoned PM, this should be a NO DUH and practiced in all forms; listening to your developers; your leaders; your customers; your team mates. The best product managers I know demonstrate the ability to listen and understand what is being said in a way that focused action can be taken. It’s not just about listening, it’s listening for understanding vs. listening until you can respond.

Empathy doesn’t come naturally for everyone.

Ask yourself. Do you often have a rebuttal to what someone is saying before they are finished saying it? Are you working to form a solution to what you think is their problem before they finish explaining it so you can look intelligent? Do you ever need to be the first to speak? If you answered yes to any of these, you might want to step back and reflect.

There are a ton of books on this topic that can help. We have a quick way to begin practicing this now and building some muscle if it doesn’t come naturally to you.

Tip: Pressure test for your own understanding

Next time you have a conversation with someone and they are communicating an experience or challenge they are having…Listen to what they are saying, then ask…

  • “Let me see if I translated what you said correctly……is that what you meant?”
  • “Correct me if I misunderstood, but this is what I heard…Is that right?”
  • “You feel X, because of Y? Is that right?”

….Find whatever words that feel natural and that politely validate you understand.

This does 2 things:

  1. It forces you to listen with the goal of understanding vs. the goal of responding.
  2. It helps the person feel heard

I will never hire a product manager unless they have demonstrated an ability to listen and empathize. If you’re breaking into PM, your resume better have a project or two that demonstrates your ability to listen to others, understand what they have communicated, and translate what you understood into some sort of action. This can be internal projects, team process improvement, a community project, etc.

I look for the same in the interview. Are they listening to me and do they understand the question/case I’m communicating instead of being poised to respond before I finish?

Curiosity.

This one can be considered a follow on to empathy, but I call it out here because I’ve seen product managers give lip service to empathy and immediately assume they have the solution to what they heard…without truly understanding the problem. Curiosity is what inspires us to ask “why.” It’s what helps us to discover the root-cause of a problem. It’s where innovation “rubber hits the road.” Building a solution to solve for a symptom is okay, but solving the root cause of a problem is where transformation occurs.

TIP: Practice the “5-Why’s”

Next time you are in a customer interview or in a meeting with a leader or a cross-functional partner, try practicing the “5-Why’s” technique. Much content is written about the 5-Whys, but essentially it’s asking “why” 5 times in response to the first answer someone gives you to a question. It’s a technique developed by Sakichi Toyoda, a Japanese inventor who’s son went on to establish Toyota Motor Corp. The technique was used within Toyota as a way to get to root cause of production issues within manufacturing.

For the best product managers, curiosity comes naturally. It’s part of their passion for solving problems and much of why they entered into the field of product management in the first place. They are naturally inquisitive when they hear a pain point or challenge from a customer, a leader, or a team mate.

Does that mean you can’t learn this behavior? Absolutely not. But it takes practice and refraining from assumptions before taking action. So take the time to ask why before jumping to an answer or solution.

Athleticism.

This is hugely valuable in smaller firms. Larger enterprises usually have very clearly scoped roles and rarely reward going outside the lines. But because 99% of companies in this country have 50 or less employees, I’m going to talk about athleticism here.

I define athleticism :

The courage to step up and go beyond the traditional product management lines and support the team and business anywhere that’s necessary. Learning quickly along the way and being resourceful where resources may not be available.

As a product leader in multiple start-ups, after my career in big corp, I realized, really quickly, that there is a huge hurdle product managers face if they grew up in big corporate and are transitioning to a much smaller firm. They find themselves paralyzed when asked to do something outside their comfort zone because they don’t have data, cross-functional “coverage,” or a known process for getting from point A to point B. In smaller companies, especially startups, we have no choice but to wear multiple hats. This is where athleticism kicks in. You identify what needs to be done, volunteer to get it done, then learn how or be creative on how to get it done…in spite of a lack in skill, process, or resources. It could mean covering things like financial modeling, writing a moderator script, designing part of the product, developing a product demo, researching and recommending a particular technology, creating a marketing plan, etc.

Every product organization is different. Some of those things may already be included in your role. Others may not. The point is not being afraid to step up and learn outside your comfort zone and demonstrate resourcefulness. The smaller the company, the more I look for indications of athleticism in potential PM hires’ resumes. And I grill hard for indication of paralysis in certain situations where they might asked to do a task they’ve never done before.

For those of you wanting to try your hand at a startup or forced to make a career move, be ready and open to discovering your new talents and getting creative on solving problems without big data, big teams or big process.

TIP: Take on at least 1 “Stretch project” per year.

When was the last time you branched out? Talk to your leader and ask to take on an impactful challenge you see in the org. Identify a project that will stretch your skills and make an impact on the customer, your team mates, or the organization as a whole. The point is to get our of your comfort zone where you are forced to learning something quickly and improvise with minimal resources.

Getting Commitment.

I saved the best for last.

A product person’s job is to lead AND execute.  It’s a unique skill mix that only a few functions within a business are required to master.  As a product person you must influence and gain commitment across multiple functions and leaders; and usually, none of them report directly to you.  It’s partly what makes our job so fun! (and exhausting at times.) So I would be remiss if I didn’t talk about the practice of gaining commitment as one of the most critical skills.  Whether you are a CPO or new product manager, this practice is critical to your success.

Getting commitment is what’s required as the first step in implementing any strategy or product decision; big or small.  Without commitment, agreement is moot. Commitment is something that many people in life, and in business, don’t understand and are caught off guard when they realize they never had it.  How many of you have recently had a decision overturned or delayed significantly? Did you diagnose what happened?

Most of the time we find one of two things happened:

  1. A stakeholder had different data and believed the decision should have been something different than the one you proposed.
  2. A stakeholder didn’t have the necessary resources (time, money, people, etc.) to execute against the decision and decided to push back after the decision was made.

As product managers we need to build a skill in getting commitment…not just facilitating decision making.

Our definition of getting commitment:

A state in which the decision maker(s) and critical stakeholders intend on and follow through on making the necessary accommodations to implement the decision made while holding themselves accountable for their part in the success of the project regardless if they agree with the decision or not.

What do I mean by critical stakeholders?  These are the folks that will be significantly impacted by the decision. These could be operational partners, your development team, your manufacturing partners, your support team, etc.  

What do I mean by necessary accommodations?  This could be anything required to execute; be it funding, human resourcing, operational or technical trade-offs, etc. 

That last part is important.  We want to be in a situation where people may not agree with the decision, but they are committed to it as they understand how the decision was made and why. 

Tip 1: Make sure everyone has the same data

Don’t cherry pick the data people! I realize it’s easy to do. There are 2-3 key data points that support your decision and that’s all you present. Commitment doesn’t work that way. Everyone has a different perspective and many are working with different sets of data. It’s up to you to level the playing field. Ninety-nine percent of the time, when people are presented with the same set of data, they usually come to the same conclusion. They may not like the decision, but because they see the data and the logic behind the decision…AND can’t provide different data that would lead to different conclusions…they will commit.

So democratize the data. Show ALL RELEVANT data to the decision and the logic that led you to your proposed decision. It may take a couple extra slide, but it’s worth it.

Tip 2: Always know what your key stakeholders need and how they will react to a particular decision BEFORE you present it.

Always ask these questions:

  1. “How are you feeling about this proposed decision?” –> I ask my most influential potential naysayers and my biggest stakeholders because I want to make sure I’m not missing anything. I also want to identify things that I might be able to address early so that they are already committed before THE decision meeting.
  2. “What would inhibit you from executing against this decision?” –> Most successful PM’s learn the impact of a decision by asking this early in the process.
  3. “What do you need to be successful?” –> Like the last question, I ask this as early as possible.
  4. “How can I help?” –> I ask this any chance I get. If I’m asking a lot of a particular stakeholder, I want them to know that I’m not throwing crap over the fence in the hopes they can suck it up. (oh yeah, that’s where the empathy skill comes in!)
  5. “When can your team have this done?” –> This is where we put stakes in the ground to drive accountability. Let’s face it. Stuff happens. So dates are still a bit soft and you aren’t nailing someone’s feet to the floor here, but you are setting the stage for accountability discussions going forward. Date’s will move, but holding folks accountable ensures progress.

These feel like common sense, I realize. But many product managers I see, present a decision without understanding the impact a decision has or who the decision impacts. They end up leaving THE decision meeting with a bunch of frustrated people rolling their eyes, delaying the decision, and backtracking with multiple people to do the homework they should have done in the first place. The secondary effect of all this could be career altering; looking tone deaf and lacking the business or organizational savvy necessary to be an effective product management leader.

So if you’re faced with the unfortunate situation of looking for a new job or just wanting to polish your product management skills during this quarantine period, be aware of the lesser talked about, but also critical skills of successful product managers.

Product Rebels is a product management training and coaching firm run by long term product executives for companies like Intuit and Mitchell International. We have trained over 200 companies small and enterprise level in the skills and frameworks that help product management leaders and product managers deliver kick-ass customer experiences.    We have a passion for finding efficient ways of infusing customer insight into everything product teams do in pursuit of experiences that customers love …that drive growth.  Join us in the Product Rebels Community on Facebook or the Product Rebels Community on LinkedIn.

Take a look at our very practical training courses and coaching programs that give you practical tools, frameworks, and support you can use tomorrow in becoming a more effective product leader.  www.productrebels.com

And stay tuned for our new book.  Sign up for updates on our new book “Groundwork. Get Better at Making Better Products”

Product Decisions in Crisis Mode

Are you feeling an urgency to make immediate changes to your product? Or trying to resist the urge to react to this current crisis? Are leaders in your organization bombarding you with ideas about how you should be responding? We’ve talked to dozens of product managers and product leaders over the past 2-3 weeks and we’ve heard many stories: teams undergoing complete pivots – scrapping all their current work and radically changing what they’re working on responding to immediate customer needs…to pulling up products with launch dates that were 6+ months ahead because they now seem to be much more relevant…to staying the course and adopting a wait-and-see attitude.

Now, more than ever, it seems critical to us that teams have to focus on core product principles to make decisions that aren’t just knee-jerk reactions, but based on real understanding. Before you stop reading because you can’t deal with yet one more thing to have to do…this core work can be done easily and quickly – and we believe can make all the difference. At least take 5 minutes to finish reading this before you completely change what your team works on.

Here’s a quick recap on the three steps that we describe as core foundations:

  1. What problem are you solving? Don’t just throw around new feature or product ideas – identify and discuss the actual customer problem. Get your team on the same page what’s the customer experiencing and why. Write it down so everyone is on the same page.
  2. Who is the customer? Is this a current customer, and if so, what’s changed in their attitudes, ability to pay, access in relation to your product. What do you know, vs what’s a hypothesis that can be tested. If this a potential new customer – how much do you understand them? Create a quick persona and build some empathy so that your solution ideas can be tested, before you start building something new.
  3. Validate with scrappy research. We know it’s hard to get to execs right now if you’re b2b, most leaders are completely unreachable. But think about who you might use as a proxy, test your thinking with someone you know who has a similar position – even if it’s in your own company. If you’re b2c, there’s a lot of people staying-in-place who are easy to access for a quick 10-15 chat – especially if you can offer a small stipend. Even if you contact just 5 customers (or prospects) – at least you’re getting out of your own head and testing your ideas.

We feel so strongly about teams needing to go back to basics that we’re offering up our foundations course for free to all product teams. This online course is less than 3 hours, usually people take this over a week, but you can cram it all into a morning. If you pick just one area to check out – refresh on the problem statement. Making radically different decisions can be justified if you have these basics in place.

Even in this crisis, let’s stay true to solving real customer problems that we understand.

Product Rebels is a product management training and coaching firm run by long term product executives for companies like Intuit and Mitchell International. We have trained over 200 companies small and enterprise level in the skills and frameworks that help product management leaders and product managers deliver kick-ass customer experiences.    We have a passion finding efficient ways of infusing customer insight into everything product teams do in pursuit of experiences that customers love …that drive growth.  Join us in the Product Rebels Community on Facebook or the Product Rebels Community on LinkedIn.

Take a look at our very practical training courses and coaching programs that give you practical tools, frameworks, and support you can use tomorrow in becoming a more effective product leader.  www.productrebels.com

And stay tuned for our new book.  Sign up for updates on our new book “Groundwork. Get Better at Making Better Products”

How to Avoid Opinion-Based Decision-Making… Do this Tomorrow

I’m sitting in a room (virtual) and facilitating a strategy session for a product leadership team. This is a very dedicated and hard working team who are also overwhelmed by a very log list of initiatives and shiny objects that have been handed down from the broader company leadership team. The discussion is centered around “I think” and “I believe” and we go round and round on what other leaders and company SME’s have conveyed to them…some completely divergent from one another. No one feels comfortable that they can propose a path forward.  Sound familiar?

I see a lot of companies struggle with this. We’d all love to say that we look at reports daily, we save time for strategic thinking each week, we stay close to our customers through ongoing, regularly scheduled interactions (be it interviews or observational sessions, etc.) But let’s face it. Most teams have a hard time just keeping up with the day to day operations.

Now, if you can shift the mindset and operations of the team to do more insight and feedback gathering as a regular practice, more power to you. We recommend it! And we have all sorts of advice and tools to help you make that transition. But let’s talk about what you can do tomorrow to be more effective at decision making and getting commitment as a bridge to this transition.

Let’s go through 3 tips you can do tomorrow in avoiding the data free zone of decision making. 

 

Tip 1:  Identify who the decision maker is vs. people that have an input

Decisions are constantly derailed by folks that feel they have a say in a decision. We’ve all been there. Someone that once was in your organization or knows the code or is a leader of a big functional organization or is influential with the leadership team…Organizations are full of folks with great intent but create massive churn in the product creation process. There is a great decision making framework called RACI. Many of you have probably heard of it.

  • R = Responsible – The person responsible for facilitating closure to the decision. That’s usually you, the product person.
  • A = Approver – There should only be 1, sometimes 2, but never more. Get clarity with your leaders and force the decision on who is the approver. And make it known to everyone involved.
  • C= Consulted – This is an important group. These are the SMEs or people that are significantly impacted by the decision. Sometimes these folks think they are decision makers. Make it clear, they are an important source of input into the final decision, but not approvers.
  • I = Informed – this could be a long list. These are all the folks the might need to know.

Action Item 1: Does your decision have a clear approver? And are your C’s clear on who that person(s) is? If not, establish this now. Put the RACI roles at the top of every decision-related communication going forward. Every deck should have the RACI in the appendix for reference. Start now. Better late than never.

 

Tip 2:  Agree & document the problem you are solving AND the criteria by which you are going to make a decision

Be clear on what you are solving for and how you will evaluate your options. Are you solving for Time to market? Cost to develop? Revenue impact? NPS impact? And please don’t say “all of the above.” No way! Prioritize. Without clear prioritization of your criteria and getting agreement on that prioritization, you’ll end up where you started; Everyone with different opinions and no one wanting to commit to a decision. Or even worse…giving you the “nod” only to overturn the decision later.

It’s always good to articulate what you are solving in terms of a business or customer problem or as an opportunity with a clear definition of success. In addition to this, I always list the criteria by which the options will be evaluated. Define what they mean and show which are most important and why. Help bring your audience along so you start the discussion at a level playing field, so to speak. If you don’t have agreement on this, then there’s no sense in continuing the conversation.

Action Item 2: Does your approver AND your C’s have a consistent definition of the problem you are solving and the most important criteria by which you will be evaluating your options? If not, establish this now. Document it and bring it to your next decision meeting…start the meeting with this. First page of the deck should always be a reminder of what you are solving and how you are deciding.

 

Tip 3: Gather the data you do have…Put stakes in the ground where data is missing.

I can’t tell you how many times I see teams paralyzed by “lack of data.” Let’s be clear…YOU WILL NEVER HAVE ENOUGH DATA. The idea is to use what you have and clearly call out hypotheses where data is lacking. Then build (and communicate) a plan for validating/disproving your hypotheses. We use “proxy” data a lot to triangulate on a solid hypothesis. For example: If you don’t know what the usage is in terms of user sessions by day, look for indicators like backend transactions or records created by day and develop a hypothesis for usage based on what you do have. Or how about this one? You don’t know the top drivers of churn in your business, then find out the task drop out rates using the system logs and understand the top support team contact drivers and make some hypotheses about what part of the experience is creating the most pain. It’s not fool proof, but it’s better than thrashing around in the data-free zone of opinions. You have to start somewhere. And data is the best place to start.

Another way to use data is to try understanding the worst or best something could be based on what you have. “The best our penetration could be in this market it 40% because 60% of this market is comprised of vertical a, b, and c which we’ve learned can’t use our product or have higher on-boarding costs, or….” Provide the starting points for deductive reasoning.

Instead of being paralyzed or attempt an opinion-based discussion, find what you can to put a solid stake in the ground or put some guardrails around the decision, so your team can confidently move forward. Be clear on where you are hypothesizing and what data you are using to make those hypotheses.

NOTE: Don’t forget to provide the team with a plan for how you will prove/disprove each hypothesis. This gives your most vocal naysayers comfort in committing to a decision (that they may not agree with, but understand how you got there) while knowing you are going to prove/disprove the hypotheses with actual data. In their minds, it means that if you are wrong, you’ll let them know and they won’t be left expending a ton of effort against a direction that is fruitless.

Action Item 3: Are you in the middle of an opinion-based decision process where you feel you don’t have enough data? Identify alternative data points and hypotheses that can help with putting some stakes in the ground that provide guardrails on the debate and guide your team to a more efficient, confident decision. I always have a page in my deck or a set of bullets in my email that talk about key hypotheses or helpful data points that minimize unnecessary debate.

 

Opinion-based decisions are painful and costly to the organization.  These are a few really quick changes you can make in your process that make a world of difference in terms of efficiency and durability of decisions.  Happy decision-making!

 

Product Rebels is a product management training and coaching firm run by long term product executives for companies like Intuit and Mitchell International. We have trained over 200 companies small and enterprise level in the skills and frameworks that help product management leaders and product managers deliver kickass customer experiences.    We have a passion finding efficient ways of infusing customer insight into everything product teams do in pursuit of experiences that customers love …and that drive growth.  Join us in the Product Rebels Community on Facebook.

Take a look at our very practical training courses and coaching programs that give you practical tools, frameworks, and support you can use tomorrow in becoming a more effective product leader.  www.productrebels.com

And stay tuned for our new book.  Sign up for updates on our new book “Groundwork. Get Better at Making Better Products”

Following Tail Lights into a Ditch

Okay, dumb metaphor but I gotta say, a lot of the training for product managers out there is pretty misleading and doesn’t get at the heart of what product management is all about. And having more and more aspiring product managers following the suggested training that I’m seeing, feels very much like following tail lights into a ditch.

I just got done reviewing another training program and found it totally disheartening. Why? Well because it seems to be touting skills that, yes are important, but that completely overshadow what’s required to be successful in your job as a PM. For all you aspiring and new product managers (and even for some experienced PMs that have gone through some of these less-meaningful training programs) listen up! Here are 3 foundations that if you aren’t well versed or don’t have a natural inclination to set before any project you embark upon, then your projects will experience constant decision delay, unnecessary rework, and customer dissatisfaction.

#1: DEFINING THE PROBLEM

Most decision overturns & delays, excessive re-work, or just plain unhappy customers are driven by a lack of shared vision around the problem. Each person on the team has a slightly different take on what the customer problem is and therefore a different take on what it means to solve it. Most training programs don’t tell you this nor do they help you build muscle to avoid this situation.

Without actually documenting the problem you’re solving in a way that clarifies what you are and are NOT solving for, slight variations in understanding will creep in and cause major havoc on the team. Vidya and I have often asked product teams to individually write down the problem for which the team is solving given a feature, a new product, or change in an existing product. Most of the time, we find that there are at least 2 people on the team that have different definitions of the problem and therefore have been advocating specific features, design elements, tradeoffs, etc. as a result.

For instance: What if you worked for a hand tool manufacturer trying to redesign your hand drill. You’ve been solving for a quarter inch drill. But guess what…The problem is not a quarter inch drill, it’s solving for a quarter inch hole. And what if it was for a quarter inch hole for hanging a 20 pound canvas? Or a 20 pound canvas on a concrete wall. Imagine if each of your team members believed you were solving for a different problem in this list. Getting agreement on functional and design prioritization would be troublesome to say the least.

Our point? As a product manager, your goal in every project is to start with a clearly defined problem that your entire team (including your leaders) has shared vision around. If not, you’re going to experience challenges every step of the way. So make sure any training you choose makes a point of helping you get to the root of the customer problem, effectively communicating that problem, and getting to shared vision with your key stakeholders around said problem. This encompasses research techniques, effective problem definition, hypotheses testing, and communication and influencing skills that many programs don’t spend a lot of time on.

#2 Defining the Target Customer

NO DUH! But I have to be honest. A lot of product management training curriculums breeze through defining the target customer or building a persona. Too often we see the target customer (persona) defined with demographics, with job descriptions, and with a couple likes or dislikes. They go into a lot of depth on market sizing, and analytics, but not in building an actionable persona.

Defining your target customer takes extreme empathy and should be enlightening and ongoing. Bringing that target customer to life, with day to day activities, but also with the relevant beliefs, attitudes, and the relevant traits that make product decisions possible.

For instance: Here are some ‘trait spectrums’ that I purposefully listen for and consider when I’m defining a target customer for software applications.

  • Organized <–> disorganized
  • Analytical <–> creative thinker
  • Tech savvy <–> tech phobia
  • Quick learner <–> slow learner
  • Confident in his/her ability to complete the task <–> no confidence
  • Patient <–> impatient
  • Extravert <–> Introvert

Depending on where your target customer sits in these spectrums will you would choose different design approaches and make different tradeoffs and even choose different vernacular in the experience.

There are many other traits that can and should be considered across different experience types (retail experiences, consumer packaged goods, etc.) The point is, it has nothing to do with demographics.

So make sure you find a training program that spends time on defining your target users in ways that are actionable in product and design decisions. This includes research techniques, actionable persona development practices, testing practices, and UX partnership skills.

#3 Contextual Customer Needs

This one is a little more elusive than the other two, I realize. So I’m going to jump right in with an example.

You are a wagon manufacturer. And there are a ton of design elements that need to be considered. Wagon size, turning radius, wheel size, wagon material, etc. The list goes on. In order to make the right design/feature tradeoffs, you’d need to know a little bit more than the problem and who you’re solving the problem for. So…

Customer Problem: I often have to make many trips carrying loads of stuff from my apartment to my car in the parking structure, which is a total hassle, can be painful, and often makes me late; especially when it comes to groceries and weekend recreational activity stuff.

Target User: People that live in urban environments that are weekend warriors (This is the short version, you’d define the intimate details now that you’ve learned a little more about how to define your target ;-))

You say, great! I know what I’m building. Hold on a minute. What if your research surrounding the problem yielded the following needs in this order of priority:

  • My parking spot isn’t close to the elevator so I have to carry my load a ways
  • Parking spots in my garage are tight; I need to be able to maneuver around my car and between cars
  • I have to store this in my closet because I use it so often and don’t have storage living in an apartment building
  • I’m usually carrying at least 20lbs+ of odd sized stuff including groceries, ice chest (that is sometimes wet,) big water containers, camping equipment
  • I’m often carrying my stuff on the sand and dirt and gravel to get to my destination “spot” (campsite, park site, beach site, etc.)
  • I have to maneuver in and out of my elevator with lots of people

Okay, now tell me if those needs don’t help you better define the solution! Clear tradeoffs emerge…right?

Without the relevant needs surrounding the problem, how do you prioritize features or make design decisions? Most product management training programs struggle to address the importance and art of these 3 foundational elements to product management..

There are some great UX programs that get at this but I’m a bit old school and believe that the product manager is just as much responsible for intimately understanding the customer and problem space as is the UX person…if not more… because the product manager must evangelize and get commitment from the organization on the resulting product roadmap and requirements. Without having that intimate understanding, getting shared vision by cross-functional organizations is almost impossible.

Bottom line here: Make sure the program you choose comes from successful product management leaders that have demonstrated their ability to define a kick-ass customer experiences that drives business growth. Make sure they enable you to set the most important foundations to any great experience. Without that, I’m sorry to say, you’re following tail lights into a ditch.

Check out our product management bootcamp if you’re interested in learning how to build the muscle around these foundational elements of product management. http://productrebels.com/

So you want to move into management?

As I write this, I’m thinking about leading two upcoming discussions on how to move into product management leadership. I’ve promoted dozens of people into senior management roles, and I’ve been thinking about what made them standout as potential managers, and what made them successful. The good news is that being a great product manager trains you already with so many of the skills to move into a management role –  being the face of the team, working with many groups, influencing to get the job done etc. So, what does it take to standout from a bunch of standouts? I want to share some interesting patterns of behavior that we implicitly look for when we have those closed room discussions with HR about who’s going to get that precious manager role. I’m going to assume all the basics are already in place: right tenure, consistent high performer, track record of delivery. If you’ve got all that, then there are some intangible ingredients that I want to shed some light on:

  1. Communicating like you’re already a manager. Often, being a great product manager means that you can communicate really clearly to your teams, and to your customers. This is table stakes. You have to be able to break down a vision into a clear roadmap, and then into workable chunks, and then into specific user stories. Product managers have this down – they know how to communicate what they want their teams to build. They’re also great at talking to customers – listening well, asking great questions, translating what they hear into needs. But being a people manager, and working with other senior leaders, entails taking all those skills and creating a different picture. Often PMs go into a ton of detail, they want to explain the work they’ve done, after all it was a ton of effort. But leaders don’t want to hear those – they want someone who can connect the business goals to the work being done in a way that makes sense. To be promotable, you have to be able to do this – it’s not a skill that execs are patient to see you grow into. If you can’t succinctly explain what you do and why it’s important for the business, you can’t get the right resources for your teams, and you can’t succeed. So spend less time explaining all the details, and more about telling a story, and connecting the dots.
  2. Working the strategy Say/Do. This shows up as how you make decisions, and how much time you spend talking strategy and actually backing up what you do with the bigger picture in mind. Product managers are expected to understand the big picture – it should reflect in their roadmaps and customer documents. But how much do you actually follow this? Someone who has “leader” written all over them is the person who asks great questions about prioritization based on strategy. Who constantly starts backlog meetings (yes, backlog!) with the bigger picture in mind. It’s not just a question of knowing the company strategy & goals, it’s how you bring them to life in the way that you work every-day. Knowing that the person you’re about to promote already “gets it” goes a long way in setting them up for a manager role.
  3. Feedback loops.  People who are going to be good managers ask for feedback. A lot. They ask after meetings, they follow-up with senior leaders, they make a point of understanding how they show up. And then they take that feedback, try something new, and then ask for more feedback. You’d be surprised how little people do this. They wait passively for 1-1’s or monthly meetings – or even, worse, their annual performance reviews. When you can see someone is actively understanding how they show up, and are genuinely interested in improving themselves – you know that they will help others do the same – which is what you want in a people manager.

Do you still want to be a manager? Are you doing these things? We want to hear – write to us and share your stories of promotion, or trying to get promoted.

It’s Product Roadmapping Season! Get some quick tips…And a helpful framework for the process

 

For many of us, roadmapping season is starting or about to start

We’re coming up to the end of the year and embarking on our new year.  And every year we walk into roadmapping with just a little dread. “Ugh, another 2+ months of research, debate, and planning gymnastics!”  “No one looks at it!” “By mid year, it’s blown up anyway!”

I’m here to tell you that if you approach it with the right principles and effort, the roadmap can be a great ongoing galvanizing operating mechanism in your company.  It can actually help you avoid shiny object syndrome too!

We should start with a couple basics…

Definition of Success of a Product Roadmap: 

  • Enables the business to achieve it’s goals; on time, within expectations
  • Provides a way for the entire organization to understand the prioritization, timing and relative sizing of solving major customer problems
  • Drives long term platform development scope & timing

We presume you have a documented business strategy and objectives that are used as a rudder throughout this process.  If not, we tell all our product managers…propose them and get agreement, so that you can build a supportive product roadmap.  I say that loosely, because it’s not that easy.  But without business strategy and clearly defined objectives/measures, what are you aiming for?  We have an online course for facilitating the definition of both if you find yourself in this position.

Okay, now for the main act…Here are some tips in achieving roadmap success:

Start with the Customer

No duh. Right?  Well, lets step back a second.  For many, this means “let’s do the features that our customers requested.”  That is not what we mean here.  Instead, it’s making sure that you have clear persona(s); personas that your team/company has agreed to.  This is not easy.  But if done right, you can actually ward off shiny objects that address problems of customers outside your persona sweet spot.  Having a clear persona helps people understand who you’re NOT going to solve in your roadmap as well.  We’ve got a couple posts on our blog about personas…try this oneContact one of our rebel leaders if you need a simple template that works!

Clearly Define Problems You’re Solving – Your Roadmap Themes

Most roadmaps are organized by 2 dimensions…time being the obvious one…and themes which are basically problems, strategies, or objectives for the business.  Each theme should be solving a very clear customer problem.  Having a clearly defined problem statement will help galvanize your team around what you are and are NOT solving for.  Having clear problem statements will help ward off shiny objects as well…”Hi Mr. shiny object thrower!  How does this shiny object serve the problems we agreed to solve in our roadmap?”  Most of the time you get “Well…uh…hmmmm….You’re probably right.  Let’s table it for now.”  The persona and problem statements help you justify tabling a shiny object.  If you don’t have those, it’s easy to get into an opinion-driven debate that usually ends up with that shiny object being added to the pipeline and other important initiatives are delayed or worse, never completed.

Facilitate Innovation/Design Thinking

You may already have clarity on target persona and a clearly defined problem AND a previously discussed set of initiatives that serve both.  Hopefully they are fully agreed to by the extended team.  But if you are questioning any one of those inputs or if you don’t have a shared vision on those inputs, then I would step back and ensure you are flexing your design thinking muscle.  Problem-driven brainstorming (with choice-ful attendees…creative minds, market experts (internal or external,) customers, partners, etc.) and other design thinking techniques will ensure the most impactful ideas are considered vs. just the squeaky wheels.  A quick set of customer interviews (5-10 targeted interviews can do wonders,) a brainstorming session, and a vote will drive far more committment than status quo thinking or focusing on the “sacred cows” in the organization.

Build Shared Vision…and Commitment

As a product manager, you’ve probably felt the pain at one point in your career of a lack of committment to the product roadmap…either someone from your leadership team, your development team, or your design team doesn’t agree with the prioritization or existence of some initiative and it makes it a painful process every time you have to justify it and ensure it’s given the attention it requires to be successful.  We’ve all been there.  Your job in this process is bringing team members in at the right time…Providing them the customer context (having them hear from customers directly is even better,) getting their feedback and hearing what their dependencies or concerns are, getting their ideas, agreeing on the criteria for prioritization of themes/efforts, etc. …And ensuring they are onboard before the final presentation of the roadmap.  Ideally, your development and operational leaders are standing beside you when presenting to the leadership team and show as much ownership over the roadmap as you do!  Yes, I have experienced this myself!

Understand ALL Your Critical Path Dependencies

Most product managers guess at their dependencies or don’t cover them all.  This is just a word to the wise.  Go through your draft roadmap with your major partners to get their input and understand what they’d have to do (development or otherwise) to ensure the initiatives can be successful in the timeframes you are expecting them to be.  As what their biggest concerns are or believe to be the biggest risks.  You’d be surprise at what you learn by going through your draft roadmap with your teams beyond just the dev team… support, operations, marketing, IT, etc.  We always think about it in terms of inputs, process, and outputs.  What are the input decisions, development, or partnerships required to begin the dev on any given initiative?  What is needed to actually develop the functionality; 3rd party software, partnerships, critical-path platform tech, etc?  And what needs to be released or ready by the time that functionality needs to be in market; partnership support teams, partnership technology or marketing, marketing technology, packaging, etc?  Think beyond mainline platform dependencies!

Ongoing Management

Once complete, we usually have a couple versions…one that’s all polished and summarized for the leadership team and one that is used for ongoing discussion as we learn more and have ongoing discussions with our core team.  We recommend reviewing the roadmap every month or two to ensure you’re managing the backlog accordingly and you’re communicating any major learning and associated pivots in the roadmap to the leadership team.  You can also use the roadmap as a tool in shiny object discussions.  “You want that shiny object added?  Are you willing to push this theme out X months for it?”  When you can have a discussion about the implications of a shiny object as it relates to a roadmap that the entire team helped build, you avoid opinion-based discussion and ensure you are doing what’s best for the customer and business.  It’s a much easier discussion.

Don’t have a clean process to take into account all these best practices?  We have a process framework that has worked for us. It’s a ratty ol’ powerpoint, but its a proven process that enables the most targeted, impactful, and committed roadmap.

Happy Roadmapping Season!!

 

 

Defining the PM job

We see this picture of PM  in the middle of UX, Tech and Business a lot:

From Mind The Product (https://www.mindtheproduct.com/2011/10/what-exactly-is-a-product-manager/)

We use this graphic as well – it’s been a nice, introductory way to speak at a high-level about the product management function, and it highlights the importance of partnering with these three important peer functions. Product management works with business leaders/marketing teams, engineering teams and UX teams. They sit in the middle often translating from one to the other. But we’ve found this picture hasn’t been sufficient to talk about what the actual day-day job of a product manager should be. When you introduce a graphic that describes the function as this small overlap of a venn diagram – it discounts the sheer amount of work and knowledge that’s required to actually do the job.

So, we came up with a new graphic:

 

This may not be the best drawn diagram, but we want to introduce it as a better way to talk about how a product manager should approach their job. We think this is far more representative of the actual  work that we all do on a year-round basis.

The outer circle goes to business. The product manager has to start with a broad and deep understanding and translating company vision, strategy and business objectives. These are the guardrails of our thinking – and we always need to go back to making sure that the decisions and tradeoffs we make are the right call for the business, industry and environment that we work in. We’ve seen lots of features go into products that customers ignore because they don’t make sense with what the business and the customer is trying to achieve.

The next inner circle is technology. This goes beyond partnering with the engineering or development team. The product manager doesn’t (often) code, but they (should) understand what the technology can/cannot do, understand the technical architecture and be able to ask the right questions, and have an engaged and knowledgeable discussion about alternatives. Without getting deep into the technology, the product manager is at the mercy of whatever technical recommendation is made. We’ve seen far too many product leaders and teams fail because they didn’t ask the right technical questions, because they weren’t prepared and didn’t dig deep enough. Technology is a core part of the job – better get used to getting into the details.

The core of the job is customer. Every part of the job is customer-driven. Whether that’s considering the product roadmap (what’s important to the customer), writing user stories (customer needs), doing customer research (talking to customers) – we could go on and on. Every single piece of work that’s produced is with the customer at heart. The product manager represents the customer at the table – they advocate for the customer, deeply understand their needs and ultimately make product decisions with the customer first, with the optimal technology and meeting business objectives.

When you look at product management this way – we believe you get a sense of how the pieces fit together and a better understanding of the expectations of the job. This isn’t a job for sissies!

Let us know what you think! We’d love to get your comments here, or send an email to vidya@productrebels.com and tell us how you see the PM job.

Persona Pitfalls

 

Okay, everyone says they know who their target customer is…Many even say they have personas.  Where does your team fit here?

Here are common pitfalls we see in most companies as they relate to effective personas (can you say “That’s us!” to any of these?):

  • Focused on demographics – age, location, occupation, etc.
  • It’s made up by an external vendor
  • Your team has a couple documented, your UX team has some, there’s one the research department created….point being there are a few and not all consistent.
  • Aren’t considered in day to day product decisions
  • Cost a lot of money for beautifully designed artifacts (designed to be displayed)
  • Lengthy (boring) descriptions or multi-page persona’s
  • Haven’t been updated since being created years ago.

Does any of this sound familiar?  It’s okay!  It’s normal.  We often don’t know how to build practical personas and understand how to use them on a day to day basis.

Here are some tips to apply tomorrow:

  • Try using a template that works.  Here’s one we’ve created (and have a whole workshop around.)  Contact us if you’d like to take our course.  Other templates work too, but make sure they aren’t exacerbating the problems mentioned above.
  • Focus on behaviors and attitudes that are relevant to the task/problem you are solving… leave demographics for last if at all.
  • Work with your broader team to finalize (don’t do this in a vacuum…include dev leaders, UX team, and research team members, if applicable.)
  • Find a picture that best represents that persona.  This will be the most memorable thing about the persona and what gets used most.  Make it a good one.  With a relevant background environment, facial expression, clothing, tools in hand, etc.  Check out a really great example of visually oriented personas
  • Post them up where everyone can see/utilize.  See examples of how some companies have done this.
  • Treat them like participants in a conversation when making product decisions…”Would [your persona’s name] actually find this valuable?  What’s the problem she/he is facing and what’s the context impacting the solution we build?”  Here is one example we use in our workshop that highlights a real world example of utilizing a persona in choosing a feature/design direction for an area of a small business software application.

You’d be surprised how many companies believe they have clear target customer definitions but when we poll the entire team (product managers, UX team, engineers, etc.) we get different definitions across the teams and different opinions about how/if those definitions are adhered to in decision making.  That makes getting product decisions made quickly and in a way that “stick” almost impossible.

Start by polling the team… are you all on the same page?