效率工具
Product Managers: Learn to Let Go
Sometimes it’s hard to let go of something after discovering it no longer works as you expect. Especially if it’s something you were passionate about. All of us, especially product managers and entrepreneurs, are faced with this occasionally.
For example, you’ve put a sprint of development effort into a new feature, and the team has now discovered new information that doubles their estimate of effort. Your Value vs. Effort estimates are out the window, and you’re now questioning whether to proceed.
You believed in this feature so much and put so much time, customer interviews, UX work, and now a full sprint of effort into the feature. It’s, well, just hard to let go.
I’m here to splash some cold water on you and tell you that all the work and energy you and your team put into this doesn’t matter.
What’s done is done, and the only thing that matters is future costs.
An essentialist product manager knows this – they know that goals, objectives, markets, and development estimates change.
I’m not suggesting that you abandon every project, feature, or idea that turns out to be more difficult than expected. Successful product managers and entrepreneurs know when to persevere despite headwinds.
I am saying that the equation has changed, and you need to re-evaluate whether it’s still the right thing to work on. If you say ‘Yes’ to continue to work on this new feature I described at the beginning of the article, you’re saying ‘No’ to other opportunities that might yield better results.
Download The Essentialist Product Manager ➜ hbspt.cta.load(3434168, 'be753440-dc4d-40c5-9808-cad744d00a28', {});
The Sunk Cost Fallacy
A few years ago, I learned about the concept of the sunk cost fallacy, the mental errors we make when deciding to continue with a project, investment, or even a relationship long after it’s become clear it’s no longer working for us.
In sunk cost theory, we will often decide to stay with something because we’ve put time or resources into it. We believe that because we have “sunk” that cost into it, we somehow need to recoup it. That’s a fallacy.
In a sense, you’re “throwing good money after bad.”
In Thinking, Fast and Slow by Daniel Kahneman, a Nobel Prize Winner in Economics, demonstrated that we choose options to avoid loss. We don’t behave logically when presented with the same choice framed in different ways.
Think of a purchase you made a few years ago that you no longer like, but continue to use because you’ve already paid for it. You don’t want the money to go to waste after all. This is the sunk cost fallacy in action.
The way to avoid the sunk cost trap is to think about how you feel about that purchase today. I think a great way of thinking is Marie Kondo’s approach to decluttering. She places past purchases on the floor and then asks whether an item “sparks joy.” If not, it’s time to donate it or trash it.
The fact that you invested money in the past is no longer relevant in the decision.
For product managers, sunk cost theory means that sometimes logic dictates that you stop working on something you’ve invested considerable time and energy into. It might mean that it’s time to sunset a feature or entire product if it is no longer achieving its objectives.
I know these decisions to abandon a project are hard. A few years ago, I was faced with this decision on a new feature where I’ve invested a lot of passion and advanced work, and the development team had spent a lot of hours on coding. It was a complex feature. As we kept discovering new cases that had to be a part of the first release, it became clear that the development effort was going to be significantly higher than we expected.
It was in our best interest to stop developing that feature and work on something easier to develop and gave customers higher value. I learned lots of lessons about avoiding these situations, to begin with, but that didn’t make the decision any easier, especially when developers I had worked closely with had been putting in the extra effort.
Make Go / No-Go Decisions Based on Outcomes
It’s never crystal clear whether to stop working on a project or dive in further. One way to manage the inevitable uncertainty is to relax about the exact plan and instead make decisions based on an outcome-driven goal.
For example, rather than creating a list of arbitrary and disconnected features for your product, instead focus on what your desired outcome is for customers – what is the goal you want them to achieve? And are there alternatives that would help you more easily accomplish that goal?
By focusing on an outcome-driven roadmap, you (and your team) have room to think about new possibilities, about different and possibly faster ways of achieving the goal. Again, the effort you have already invested rarely matters in that decision.
[Free book] Backlog Refinement: How to Prioritize What Matters ➜ hbspt.cta.load(3434168, 'ba6d6ffb-c21a-41c0-8f7e-7f79e553dae1', {});
Revisit Prioritization
When the equation changes (either the effort you need to exert or the outcome you expect has changed), it’s OK to revisit your priorities and evaluate whether you’re working on the right things.
If you use a roadmap prioritization framework such as LIKE.TG’s Planning Board, you can use the weighted scoring model to re-score the project against other items in your product backlog. Product managers know that it’s acceptable to re-evaluate opportunities (and work in progress) to assess if the roadmap still has the right priorities.
Does this sound familiar? As a product manager, you’ve finally got a groomed backlog that aligns with the product vision and roadmap. Teams are cranking away and delivering. Everything is on track and then it happens—some unplanned work pops up that is deemed URGENT by someone outside your department. All eyes are on you to set the priority—do you have the tools to do it?[/caption]
Focus on today (and maybe a few sprints out).
Product managers expect to spell out our products’ vision, and the product looks like one or two years down the road. But it’s problematic if this planning is too detailed. One or two years out, any plan is only a fantasy and a waste of time. This thinking can keep you too biased towards completing that plan, rather than asking if it’s the right thing to be working on.
There’s no way things will go exactly to plan, and the goalpost will probably change along the way. You’ll never achieve perfection. Unfortunately, this detailed planning sets an expectation in your head (and your stakeholders’ heads) that won’t come true. It sets up everyone for disappointment.
My advice: Don’t plan too far ahead. Focus on the big picture vision in broad terms. Then, focus on what is in your control today to meet that vision. For your product planning, a few sprints out are far enough.
Embrace Uncertainty to Make it Less Stressful
In the past, I’ve wrestled with needing to control uncertainty. For years I thoroughly planned most everything and felt the need to know the eventual outcome of decisions. I spent a lot of time that, in the end, wasn’t necessary.
Uncertainty is uncomfortable, so I often found myself with a lingering sense that things were out of control. As a product manager, the uncertainty manifested in really detailed and lengthy Product Requirements Documents. I know I’m not the only product manager with this challenge. All of the research, time spent writing long documents, and time spent worrying were, well, non-essentialist.
Over the years, I’ve realized through observation and personal experience that the most successful and happy people are those who are willing to embrace uncertainty. They are the ones who make “risky” decisions without knowing 100% of the information. It’s especially true for product managers, entrepreneurs, and others who want to launch products or ideas.
I’m much better now about letting things unfold without needing to know how the plan eventually will materialize. And yes, I get the irony that I’m the co-founder of LIKE.TG, software that helps product managers visualize their plan.
If we can stop for a moment and change our thinking that we’re not in as much control as we think and surrender to it, we’re more likely to succeed because we’re open to change and opportunities we wouldn’t see otherwise. And I’ve realized these opportunities somehow align with my most important goals.
hbspt.cta.load(3434168, 'd3fa5225-9b84-4eae-8910-23016a8b8f99', {});
Learn More
To learn more about letting go of what’s not working and making a more meaningful contribution to your product management career, download my free book, The Essentialist Product Manager. This book blends my passions of essentialism and product management into ideas that you can bring into work and your life to make it all more fulfilling.
Download The Essentialist Product Manager ➜ hbspt.cta.load(3434168, 'be753440-dc4d-40c5-9808-cad744d00a28', {});
When to Declare Backlog Bankruptcy
A few years ago, I was the acting product manager at a startup, developing an enterprise software product. Building the product was hard: it was taking longer to develop than everyone expected (of course). The complexity of what we were trying to accomplish became more evident as each day passed.
The product backlog I managed grew daily. I heard requests from customers, domain experts, consultants, our development team, and internal stakeholders. And I diligently added the stories to the backlog. Feature request? Add it to the backlog. Bug found? Add it to the backlog. Corner case we needed to handle one day? Backlog.
Declaring Backlog Bankruptcy
I diligently prioritized and managed the epics and stories, moving them into the next two or three sprints in the sprint backlog. As the months passed, it became clear there was no way we’d be able to develop what was in the product backlog over the next few months. There was rising frustration from the whole team at the pace of development, partly from the perception that we would never get to everything.
And every day, my stress grew as the backlog ballooned.
What was the point of diligently managing the backlog when it would be impossible to accomplish it all? Especially when everything a few months in the future would likely be different?
So along with the CTO, I made a decision – we’d declare backlog bankruptcy.
Every story, issue, bug, and idea that we weren’t planning to release in a near-term sprint, I would delete. Clicking Delete was one of the harder things I’ve done. Over 600 items… gone.
But then something interesting happened. There were no repercussions from that decision. And I got a sense of relief after eliminating the cognitive overhead created by the backlog. And after ruthlessly prioritizing and limiting what we added to the backlog, we got the product to market faster. Starting from scratch felt GOOD.
The lesson declaring backlog bankruptcy taught me was that if an idea has high enough value for customers, it will come back. It will bubble up to the top. I no longer keep massive lists of all the ideas and things I want to do in the future. Sometimes the simplicity this creates in your product is a positive experience for customers.
It also taught me more about the purpose of the product backlog – it’s not a place for every future opportunity. We needed to have a process around what gets added to the backlog.
Download the free Backlog Refinement: How to Prioritize What Matters Book➜ hbspt.cta.load(3434168, 'ba6d6ffb-c21a-41c0-8f7e-7f79e553dae1', {});
What Does a Healthy Backlog Look Like?
Every organization doing agile software development does it a little bit differently. My approach isn’t for everyone, especially for organizations that need to have more certainty about their product roadmap more than a few months out.
For me, I’ve been a part of startups using only some variant of scrum. We plan the stories a few sprints ahead, guided by the epics and themes on the product roadmap. That’s typically enough for any product manager. Ideally, there aren’t hundreds of stories in the backlog.
hbspt.cta.load(3434168, '3f36d63f-fe4f-400d-ab83-a64b28767625', {"region":"na1"});
When the product backlog is too long, it clouds the vision and creates underlying stress of what’s not getting done. A shorter backlog frees you up to think about what’s most important. It improves creativity. Think in timeframes of perhaps three to six months out.
Think about your process for what gets added to the backlog. It’s not for every possible “future” idea that you haven’t necessarily committed to. Yet you still likely want to track ideas and inspiration you’re getting from customer interviews. And you might want to remember who asked you for a particular feature so that you have context. For those situations, I recommend creating a separate “future opportunity” list, so you have a place to add your learnings as you proceed with customer discovery on the idea.
After having been involved in launching multiple products over the years it’s clear to me that things you think are super important today aren’t as pressing a few months from now. So by adding every idea to the backlog, you’re doing yourself a disservice.
But the stories and epics that you believe will add lots of customer value in the short term go for it. Also, it’s good practice to include bugs, tracking them and peppering them into near term sprints.
hbspt.cta.load(3434168, 'a4593ff5-0cd1-4437-86db-eff7703f0d47', {});
Warning Signs Your Backlog is Unhealthy
As a product manager, how do you know you’ve entered the dangerous territory with your backlog? Here are some of the things I’ve found to watch out for:
Your backlog has become a dumping ground for every random idea from every stakeholder. Sure, it feels good to be able to tell a vital stakeholder you’ve “noted” their opinion, but is the minuscule, incremental cognitive overhead worth it if you do that 100 or 1,000 times?
You’re adding ideas that you’d like to implement “someday.” This thinking is long-term, and because everything is guaranteed to change from a product, customer, and competitive standpoint, what’s the point? I suggest deleting anything in your backlog that is older than six months.
You’re spending hours every month prioritizing items that aren’t winding up in your short-term sprint backlog. Be thinking every day about what will provide customer value in the short term.
Sometimes You Need to Add More
Now, to be clear, there are many situations where you might want to add something to the backlog even if it’s not going into a near-term sprint. For example, if your CEO believes a feature has merit, and you want to validate the idea and at the same time let them know you’ve noted it in the product backlog.
If you absolutely must keep a long product backlog because it’s necessary from a corporate or process standpoint, try organizing it or grouping it by a theme, such as “near term” and “long term.” That might help a little bit with your sanity.
As I mentioned previously, you don’t need to track everything that goes into your product backlog. You can use a separate “opportunity” or idea backlog, such as the Table Layout in ProductPlan. This approach is a great way to capture ideas that you haven’t committed to, and that need further validation.
My decision many years ago to declare backlog bankruptcy has yielded so many lessons for me since then. By the way, out of extra caution, before I clicked Delete, I exported my product backlog. And I never went back to look at it.
Want to learn how to efficiently funnel backlog items onto the product roadmap?Read Your Guide to Product Roadmaps hbspt.cta.load(3434168, '019ceee1-45ce-493c-8270-b738861f2296', {});
Meaningful Product Processes with IMPACT
After reading a blog or a book or attending a conference or talk on product management, I’m always excited to try out the new processes and frameworks I’ve learned about. I try to get my team similarly enthused about this endeavor. But when I check in with them in about a week, you can barely tell that anything had changed… mostly because it hadn’t.
We tend to fall back into how we were doing things before because that cool new process isn’t meaningful in itself. Without the context for why it’s the most important way to spend our time, it wasn’t worth investing in making a change.
So when I tried coming up with my own mindset and mantra for improving product management, I found myself elevating above the flowcharts and execution strategies, looking for something more universal. I wanted to tie together the entire ecosystem and to identify a unifying measuring stick. Something equally applicable to how we prioritize projects as it is to our own careers.
Most importantly, I wanted to invest our time in something that will stick and make us all more productive and efficient product teams. Thus came the genesis of IMPACT, where six words can create a lens to reexamine everything a product professional does to ensure it truly is creating an impact and maximizing the opportunity.
Meaningful Product Processes with IMPACT
Solving Interesting problems that are Meaningful to People, with Actionable plans that are Clear and Testable. That’s what IMPACT’s all about, and if we’re not infusing our processes with IMPACT, then we’re potentially spending our energy on the wrong things.
Download IMPACT ➜ hbspt.cta.load(3434168, '76387af0-7ef4-49da-8b36-28e99e4f5ba3', {"region":"na1"});
Interesting
By making the problem interesting, we start to build momentum. People need a reason to care, so it’s imperative we tell stories and use our storytelling skills in everything we do.
By helping our audience—from sales and marketing to engineering and QA—connect with the customer problem, we will drive better outcomes. We all know that when we focus on value over features, everyone’s happier.
The processes with IMPACT that help ensure we’re working on interesting problems include:
Product discovery—Helps you better understand the customer problem and interestingly tell that story.
Ideation validation—Uncovers more meaning.
Market research—Reveals how others tell their stories and perceive the audience.
Customer feedback—A door into what’s happening and the trends and evolution in the market.
Community involvement—Take any opportunity you can to be where your customers are and get more chances to hear their stories and the challenges they face.
Event participation—Talk to people and learn about their lives outside your product for invaluable context.
Meaningful
Is your solution meaningful to the customer or the business? Remember that excitement about an idea doesn’t always translate to value. The real test is how much they’re willing to pay for it, which truly shows how much they value the solution.
Aside from generating revenue, it’s also important to check if the solution aligns with the business’s direction, vision, and values. These processes with IMPACT can help you articulate what’s meaningful to business:
Vision Mission—Although it’s often handed down from senior management, it still influences your work. You should be able to articulate how your solution aligns with the vision and mission. Then, prioritize things when necessary to create those connections.
Strategy/Strategic Alignment—It should include a definition of value that the product is trying to deliver and what success looks like.
Gracefully Saying No—If that really compelling idea doesn’t create meaning, communicate that to teams and customers ASAP, then move on.
Roadmapping—Include components of the meaning and value you’re creating, as well as why it’s the right thing to do.
People
You must figure out the pervasiveness of the problem you’re solving and how many people will care. What will solving this problem unlock in the market?
Alongside understanding your research in solving the problem with a specific solution, it’s also essential to know how that investment may accelerate other innovations or solve related problems. This can lead to exponential growth and new opportunities beyond the original scope and scale of the situation.
By using as broad a lens as possible, you can also determine if you’re making a big impact for a small number of people or a small impact for a big number of people… both of which are worthy and sound investments, assuming there’s a willingness to pay. These processes can help quantify things:
Competitive Analysis—Helps you understand which problems competitors are solving and how they frame them. Not to mention figuring out which ones they’re NOT solving.
Market research—Helpful, but determine upfront how much you need to know to be confident to move forward to avoid analysis paralysis.
Surveys—Determine who cares about this problem and how frequently it occurs.
Jobs To Be Done/Opportunity Tree—Another tool to assess the problem’s pervasiveness and how big a deal it really is.
Prioritization—Be sure you’re accounting for the people that will be impacted by value creation. Not catering to the whims of internal stakeholders or finicky edge cases.
Segmentation—Use this to define your target market and zoom in on the people who will truly benefit and appreciate the value of your solution.
Actionable
Coming up with a great idea is pretty easy. Go ask a first grader, and they’ll give you some amazing, innovative ideas… that are completely unfeasible. Your job is to narrow things down to what’s possible, reasonable, and probable.
You need to know you can deliver the solution, regardless of how big or important the problem is. These processes can serve as a reality check on what’s truly doable:
Squads/Team Composition—More effective teams, benefit the entire company. They must be constructed to get an optimal cross-section of talent and compatible personalities and work styles.
Product Development processes—Find time to evaluate feasibility and LOE as early as possible to avoid wasting cycles un impractical pathways.
Ideation/Validation—All ideas are welcome, but only those truly actionable given how the solution is framed should be pursued.
Dependency Analysis—Larger teams, create more dependencies. Those dependencies increase the odds that the market will pass you by while you sort things out.
Clear
To build consensus, generate enthusiasm, and win over skeptics, you must be able to articulate the value statement of the solution clearly. This not only will help you secure resources and support for the project, but it also has a downstream impact on sales and marketing, as well as eventually how customers react to the value proposition.
Some key processes contribute to making sure the impact of the solution is clear to everyone:
Roadmap/Road Show—You want to make sure it’s in front of audiences frequently enough that it’s current, accurate, and remains top of mind. This is especially key when there’s not yet a lot of trust in you or your ideas. It’s also crucial to ensure the roadmap presents the right amount of information for the specific audience. You don’t want to drown them in details or rush through the items they particularly care most about.
Alignment—You want to be sure you’re all using the same language, OKRs, prioritization, etc., so you’re all happy with the result.
Cross-Functional Collaboration—Evaluate how and when you interact with peers to be sure it’s frequent enough. These interactions should be in settings where they’ll feel heard and can have their concerns addressed.
Documentation—People don’t read (except amazing blog posts like this!). Is it accomplishing what you need it to do? Does it match the TLDR summary you included at the top?
Testable
Humans aren’t very good at knowing what they need, just articulating what they THINK they need. Therefore you must validate that the planned solution is valuable as early as possible.
Embrace the sunk cost philosophy early and often. Additionally, don’t be afraid to walk away or initiate a significant course correction at any stage. This is only possible by leveraging processes that put your ideas to the test:
Agile Product Development—Agile is about more than replacing waterfall; it’s how you can test, learn, and adjust. With Agile, you can forward efficiently while leaving room for learning moments and making corrections based on those findings.
Beta Processes—It’s never too late to learn and change. Set expectations internally and with customers while capturing feedback during beta tests. Thisisn’t just a dress rehearsal but rather a chance to get real-world experience on what you think will work.
Iterative Design—Boil things down to the smallest step you can take to deliver value. Then test, learn, and repeat.
Usability Studies—You need tools to test and verify. So watching real customers try to use your product is one of the best options there is.
For more insights into how you can apply IMPACT to your processes, watch the webinar or download the free e-book today.
The Most Under-Appreciated Product Management Skill
We write a lot about the skills that product managers need to be effective. The skills are wide-ranging, from ruthless prioritization, the ability to build consensus with stakeholders, metrics-based decision making, and a host of other business and technical skills.
Those tend to be the skills that we and others talk a lot about. But what are the most under-appreciated product management skills?
To answer that question, we asked several product managers for their thoughts. Here is what we heard.
My Favorite Under-Appreciated Product Management Skill is…
I’ll start with one skill I think is under-appreciated: silence.
By silence I don’t mean not speaking, but rather, knowing when to listen intently and then speaking wisely. Too often, we believe we’re expected to have all the answers.
Silence and listening command respect.
Silence works wonders in so many scenarios. When interviewing customers to make sure you truly understand what they think. While working with engineering counterparts or UX colleagues to understand their perspective. When discussing priorities with stakeholders. In these situations, silence (followed by thoughtful responses) shows you’re valuing the opinions and insights of others.
Download From Product Manager to Product Leader ➜ hbspt.cta.load(3434168, '67d2717f-2575-4049-9733-48a5e23d53c4', {});
Crowdsourced Picks
I solicited input from other product managers on which underrated product management skills they value. I’m sharing their top picks with you.
Intuition
For Dieter, a product manager, the innate ability to know the right thing to do doesn’t get enough credit. We’ve preached so much about how we should ditch our gut instincts and hunches. We prize data-driven decision making. But we’re sometimes ignoring the value of our own wisdom.
“We have hundreds of methods and tools, but sometimes the solutions come from within…”
Optimism
Product managers must consider the things that might go wrong. We have to set reasonable expectations then mitigate challenges with delivering solutions on time.
This caution and prudence are rightly part of the job. But Stef thinks there’s still plenty of room for a rosy outlook. Her top pick for underappreciated skill:
“Optimism! This can be better. We can do it. These setbacks aren’t the end of the world.”
Multitasking
Product managers have so much on their plates. The role requires attention to disparate details.
Keeping tabs on KPIs, dealing with a demanding customer, attending standups, updating financial forecasts, and scheduling customer calls might sound like a crazy week for most people. To a product manager, it looks like a Tuesday morning.
That’s why product manager Shreya believes multitasking is the most valuable under-appreciated skill for product managers. Product managers exist in an environment full of entirely unrelated demands and deadlines. There’s a lot to do, and sometimes it all seems to need to happen today.
Shreya says “The most under-appreciated skill is multitasking. I couldn’t agree more on adaptability and humility. Product Managers need to wear several hats and adapt based on the ‘n’ number of factors and see what the changing user needs are demanding. Then humility helps to understand various possibilities and perspectives.”
Problem-solving
Products we build solve problems for users. So hopefully, product managers are already in a problem-solving mindset. But sometimes identifying what the problem is in the first place can be tricky. What is the value of solving the wrong problem?
That’s why problem-solving ranks at the top of the list for Praseen, a product manager:
“For me, I would say the most under-appreciated skill is to ‘figure out and define the problems’ I should be working on. Most of the cases, what you do daily as a PM is undefined, and to add value, one must first learn ‘how to add value.’”
Internal stakeholder empathy
Empathizing with customers is nothing new in the list of product management skills. Customer-centric organizations put this goal above all others. It (theoretically) drives every decision they make.
But for Aniket, there’s a less-discussed form of empathy not getting its due: Empathy with internal stakeholders: “We hear about empathy towards customers, but empathy towards internal stakeholders is equally important, which goes under-appreciated.”
Having empathy with the sales team, engineering, and executives is essential. Are product managers as empathetic in these stakeholder engagements as they would be when hearing a customer’s frustrations and wishes?
Humility
Product managers are subject matter experts. They’ve spent countless hours researching, interviewing, and testing. They know the ins and outs of their products. They’ve crafted compelling value propositions and perfected product positioning.
But for Paul, the expertise and confidence generated by that hard work can make you an expert, yet product can always learn more from customers, prospects, and stakeholders. Instead of settling for their current level of knowledge, they should always yearn for more.
Paul says “Humility is a critical skill for product managers. Recognizing that what you ‘know’ is only an assumption. Acknowledging that everyone you interact with has something to teach you means you’ll never stop getting better.”
Adaptability
Product management is not a career for people who want to do the same thing every day. It’s about the furthest you can get from working an assembly line because the demands of the job require the mental nimbleness to switch from one task to the next. These duties span a wide assortment of domains and deliverables.
For product manager Carey, rolling with these changes but thriving in that environment is a top unrecognized trait. “The most under-appreciated skill is adaptability: The ability to change, to see change, to re-frame, to re-assess.”
Reading the room
In a similar vein, product manager Jay also believes a product manager’s ability to change is critical. He particularly values the mental and emotional awareness and dexterity to modify one’s approach based on the specific team you’re working with.
“Assess your development team’s maturity and adjust your approach accordingly. With an experienced team: don’t get in their way, ask questions, focus externally. With an inexperienced team: be more assertive and guide the team with best practices you’ve seen work before (assuming you know what you’re doing, of course), check-in frequently, use conservative timelines.”
Jay also prizes the capacity for gauging your capabilities for the challenge at hand.
“On the flip side, you also need to assess your subject matter expertise and act accordingly. Sometimes you know the customers, market, competitors, etc. Other times, you take over a product where you have far less expertise, and you need to eat some extra slices of humble pie.”
hbspt.cta.load(3434168, '3f36d63f-fe4f-400d-ab83-a64b28767625', {"region":"na1"});
Common Threads
In reviewing these responses, I found some patterns. There’s a universal emphasis on product managers knowing themselves, being better coworkers, and optimizing their workdays. Most of these were soft skills.
I think that’s because product managers depend on others to deliver great products. It’s a collaborative process. Developing and improving the skills that emphasize those aspects of the role is always appreciated. Even if it never shows up on a job description.
Want more leadership tips?Read the Career Guide for Product Managers hbspt.cta.load(3434168, '51f4627c-aefd-4981-92a8-41fe12455dbe', {});
The Key to Achieving Change Management Buy-In
Getting change management buy-in is not easy, but we’re only delaying the inescapable when we resist change. Whether it’s driven by economics, technology, politics, or the environment—those massive undercurrents can at best be held at bay before reality sets in.
Most organizations are resistant to change by default. Inertia, process, bureaucracy, and governance are often cited as the primary hurdles. But fear and uncertainty also play an often unspoken-yet-prominent role. The bigger the company, the harder it can be to make even the smallest fundamental shifts.
Yet, those same large organizations face the most risk by not adapting quickly and intentionally. Smaller, younger firms are by nature more agile, and it’s easier to get change buy-in. But small teams also have less to lose. It’s because larger, older companies have so much more at stake that failing to change can be that much more consequential.
For example, my mission in my previous role at a company with over 30,000+ employees was to create a formal change management process or track record to lean on for their CRM system, Salesforce.com, and create a center of excellence around optimizing the firm’s usage of this critical tool.
This wasn’t my first time helping an organization improve its Salesforce.com utilization. I’ve done this for multiple firms from a project management/PMO perspective. I’ve also had experience in change management, having spent eight years previously facilitating those.
Let’s look at the critical steps that can affect the fate of significant transformations for organizations and successfully change management buy-in.
3 Critical Considerations That Affect Change Management Buy-in
1. Intentional thinking from the start.
One fatal flaw many big change initiatives make is letting things “into the wild” before they’re fully baked. However, there might be a follow-on phase to tweak and tailor new tools and processes to the specific impacted groups. Employees won’t always wait until the paint is dry to begin using things.
I’ll use Slack as an example. The asynchronous communication tool can be a huge boost for efficiency and collaboration. But when left to their own devices, early adopters can create some bad precedents.
In this case, if you don’t create the correct channels and train staff how to use Slack properly, it can get out of control. This can both create bad habits and turn people off to the tool before it’s spun up. Yet, a productivity boon can end up as yet another system people use inconsistently.
2. Anticipating downstream ramifications.
Management often initiates changes. A CFO, VP, or a Director thinks there’s a better, cheaper, or faster way to do something. Then they issue an order, and everyone beneath them in the organizational chart deals with the consequences.
But managing change by edict is often a recipe for disaster on the ground floor. Executives frequently don’t have much insight into the day-to-day operations of various teams. Thus they can’t begin to recognize the disruption such a shift might cause.
The power of working groups is effective. People on the ground are the ones that know what’s going on.
Ideally, before a suggested change is even approved, the organization conducts a full forensic analysis of the implications for everyone impacted. That includes employees across the company, as well as strategic partners and even customers. The exercise might uncover potential unintended consequences.
Regardless of how big or small it might be, every change requires a proper communication plan. The key is figuring out how you’re going to engage with everyone, drive adoption, detail the benefits, and get everyone on board.
It should detail the rationale for the move along with any new or modified processes. If necessary, hold training or QA sessions to ensure the roll-out goes smoothly with minimal turmoil during the transition.
3. Centralized change management.
Another key to successful change management is running it all out of a single unit, be it an ad hoc team, a more permanent center of excellence, or a formal PMO. There are many benefits from this kind of organizational structure.
First, it breaks down silos in a way that’s often unattainable organically. This unit can both communicate across the organizational matrix and identify redundant efforts.
This also puts trained practitioners in charge of structuring and facilitating these activities. Since this is what they do, they have the skills, tools, best practices, and resources to make things as seamless and standardized as possible. They also possess the institutional knowledge and expertise to anticipate friction points in advance thus minimizing potential damage via education and well-documented processes.
Most importantly, utilizing a dedicated change management entity gives a holistic view of every major initiative. Regardless of where it began, keep in mind the entire organization and larger ecosystem during execution.
Read the Strategic Roadmap Planning Guide ➜ hbspt.cta.load(3434168, '06f68ad8-23a4-4d4e-b15a-e578f0f8adaf', {"region":"na1"});
4 Steps to Achieve Change Management Buy-in
These are the steps for starting things off on the right foot.
1. Survey the landscape.
Until you’re on the inside, it’s hard to know who the real players are. Nor do you know where the power centers lie and which baggage and political legacies influence projects. You see which names are being dropped, who people defer to, who made previous critical decisions or threw up roadblocks.
At one point, I conducted 40 interviews across various groups to get the land lay but could have done more. Once I’ve identified these stakeholders, then I can understand how to best engage with them.
I want to emphasize that it’s imperative to make sure you get things right when evaluating senior management. You need to know their motivations, concerns, and what they value most.
Emotional intelligence is such a key factor as a leader. You can talk about industry knowledge and business process. Still, if you don’t have the emotional intelligence of people around you and their drivers, then you can’t figure out how to motivate them in the best way.
Additionally, not everyone wants to receive information in the same way, nor do we all process it similarly. I make a point of asking key stakeholders right off the bet how they like to be communicated with, so I can try and meet them where they want to be.
2. Define and articulate a vision.
No one’s a fan of change for change’s sake, so the value and purpose of this new role must be crisp, clear, and concise. From the C-suite to the cubicles, everyone should understand why this is important, the steps required, and which benefits the result will bring.
Ideally, present tailored messaging for different audiences to connect with their pain points and address their concerns. But to do this, you need to know who you’re dealing with.
I use the Insights method. To follow this method, first place stakeholders along a color spectrum, and then based on that designation, you can see what triggers stress along with the best ways to remedy that state. I do this to create the best chances for a successful interaction by acknowledging their feelings and speaking to them constructively.
It’s also critical to not immediately dive into the details but rather to establish broader themes that the change will encompass. These themes might seem obvious at times, but a smart and accurate tagline for the initiative can become a helpful mantra and reference point for the project’s life.
3. Get change-buy in with a roadmap.
Significant changes have a lot of moving pieces and dependencies. To get change buy-in, a project or program roadmap can help illustrate exactly how everything will happen. Using a purpose-built roadmapping tool is the answer to keeping everything organized and a clear vision to stakeholders.
Using LIKE.TG, I capture every possible backlog item to ensure no requests or requirements get lost in the shuffle. In this central repository, we used LIKE.TG to prioritize initiatives. I categorize various things up for consideration before putting them into “buckets” to develop and ship together to create incremental value associated with a particular theme.
Then I use a cost and complexity versus impact method for evaluating which items should get to the front of the line, and are happy to slot the low-hanging fruit in the front of the queue to deliver more value to stakeholders faster.
With prioritized themes set, I build my roadmap. I use lanes for “containers” of specific items, which allows me to keep the roadmap clean and straightforward. Less is more about the level of detail presented to most audiences, but there’s always the option to drill down and get more refined information on a specific roadmap element.
hbspt.cta.load(3434168, '3f36d63f-fe4f-400d-ab83-a64b28767625', {"region":"na1"});
4. It’s all about people.
While tools, frameworks, and processes get a lot of attention, at the end of the day, what determines a significant change’s success or failure is how it is embraced and supported by the individual it impacts.
The key to change management buy-in is having a clear vision and structure people understand so they see the impact of what you’re trying to do and how it affects them. If you don’t think about how they’re going to go about it, it will never be successful. Without engaging with the people who will use it, that will be your number one failure.
Why Gender Diversity Leads to Better Products
The IMPACT approach to product management’s primary goal is creating the maximum value for the broadest target audience while remaining aligned with the company’s mission, vision, and goals. Filtering everything through the IMPACT lens can be extremely beneficial. It helps product teams level set every action, process, and decision to ensure they’re staying true to that objective.
But if there’s one part of product management that needs IMPACT more than anywhere else, it’s roadmapping. Roadmaps set the tone for the coming months and years. They typically direct dozens—sometimes hundreds—of people involved in the implementation and rollout of product releases. Not to mention they dictate what marketing and sales will be able to promote and sell going forward.
No one wants a plan for the future that isn’t exciting, inspiring, and positioning the product for growth and success. Yet far too often, bug fixes, custom client requests, and features of dubious value take up valuable bandwidth. These items snap up spots on the roadmap that would be better filled with innovative, value-added customer benefits and revenue-goosing enhancements.
Where trouble begins
Most product teams don’t set out to create lackluster roadmaps, but they’re often dealt a sub-par opening hand. You ideally begin with the company’s mission and vision. However, many organizations aren’t great at strategy, so there’s often a disconnect between those lofty ideals and reality. Senior leaders’ KPIs and metrics fixate on don’t always align with the long-range objectives and key milestones required to get there.
This leaves the next crucial steps up to product managers. Yet PMs are sometimes given little direction when it comes to setting priorities and goals. This doesn’t prevent them from being met with withering criticism or—even worse—deafening silence when coming up with and presenting a plan. So these roadmappers need a rubric to continually measure the overall impact of their blueprint for the product, and IMPACT can do just that.
Laying the groundwork for a roadmap with IMPACT
IMPACT doesn’t begin with the roadmap. It must be part of the process in earlier stages of product development, particularly during prioritization. According to its own impact, vetting and judging each potential roadmap item culls the herd and eliminates requests and ideas that won’t move the needle where it matters most.
IMPACT also shouldn’t be thought of as a component of the roadmap. There shouldn’t be any swimlanes dedicated to each letter of the acronym. Nor should “Clear” or “Actionable” appear in the legend.
IMPACT’s value comes into play in a few other ways. First, by utilizing the IMPACT scoring approach during prioritization, there will be far more confidence it consists of worthy endeavors stakeholders will agree on merit inclusion.
The roadmap’s overarching themes should also stand up to the IMPACT test. Each major goal and the desired outcome should meet the same criteria that any individual development items have already attained.
You can also judge the roadmap as a whole based on its IMPACT. Looking out six, nine, or twelve months, will the planned themes and projects deliver results that adhere to this credo? If not, what’s driving the prioritization of work that doesn’t improve things along these lines?
Staying true to a roadmap’s true purpose
Product roadmaps aren’t projected plans, schedules, or a laundry list of deliverables. Not that stakeholders don’t try to turn them into that occasionally. You can’t necessarily blame them—these folks are desperate for updates and information that they can use tactically to do their own jobs.
Despite this frequent bastardization of purpose, product roadmaps are supposed to be about why you’re doing something as much as they explain what it is and when it might show up. To shift that mindset, product managers must change up the internal conversations around roadmaps and evolve the organization’s product culture. And here’s one more opportunity for IMPACT to play a role.
hbspt.cta.load(3434168, '7c551d2b-ed71-444c-888b-18461bcb6944', {"region":"na1"});
The roadmap is a canvas to tell a story, not a checklist or Gantt chart. And that story is laced throughout with IMPACT. Everything on there should fit the narrative, benefitting users while advancing the corporate strategy.
I personally structure our roadmap by value areas—the value we want to deliver to create that impact. I then structure the legend to reflect our differentiators. Before I actually put anything on the roadmap, its bones already indicate what’s most important for our business.
With that foundation, I can start looking at opportunities, resources, and investments. Combined with using IMPACT for prioritization within each area, I know the product delivers value in all of the most impactful areas.
Interesting
Roadmaps are a way to tell your story visually. They connect your audience with the journey, so they walk away with the most pertinent information. Regardless of what the roadmap contains, it all comes back to why you prioritize that work and tell a story that belies the successes and victories to come after implementation.
Meaningful
Tailoring your roadmap to specific audiences is key by leaving out anything that distracts from the narrative or isn’t relevant to each stakeholder. External customers need to see which problems you’ll solve for them in the coming year. And internal stakeholders want to connect the dots between what’s on the roadmap and their impact on OKRs and KPIs.
People
Put yourself in the shoes of the different people your roadmap is for. Next, customize it for their own areas of interest and concerns. With this relevance top of mind, decide which parts of the roadmap you want to share, how far into the future it should go, and which methods are most effective to communicate your plans.
Actionable
Every roadmap is “actionable,” assuming things are implemented according to that plan. But I tend to worry about what I expect the audience to do with the information they’ve just received? I’m looking for customer validation and feedback, sales and marketing to update their pitches and collateral, customer success to anticipate how they’ll roll this out to customers, and how the technical teams will determine feasibility and make things happen. That means my roadmap needs the necessary information and context to enable these behaviors and actions.
hbspt.cta.load(3434168, '76387af0-7ef4-49da-8b36-28e99e4f5ba3', {"region":"na1"});
Clear
Roadmaps should answer existing questions and not raise too many new ones—you’re shooting for generating excitement, not doubts. That’s why conveying the why is vastly more important than the what. Measure their engagement and comprehension based on the questions they ask.
Testable
Roadmaps can also be tested by trying them out on different crowds. Socializing your proposed plan with small groups can generate valuable feedback instead of waiting for a grand reveal and falling on your face when presented with a tough question. Creating that space for failure and challenges gives you additional opportunities to polish things up while also acknowledging that your course may vary based on an always uncertain future.
Impress them with IMPACT
If your roadmap holds up to the IMPACT test, you can confidently enter any presentation. You’ll know that even if everyone doesn’t agree or approve, they can’t argue with your rationale or reasons. You could still get overruled by an executive or a flagship customer, but you can still stick to your fundamentals even if a few wrinkles are thrown your way.
Most importantly, you’ll have value creation on your side as you lobby to retain the items you know will create the most impact for customers and the business. For more examples of how IMPACT can guide your product management endeavors, download the free IMPACT ebook today.
Watch Annie talk through IMPACT: Processes in the webinar below.
How I Overcame Imposter Syndrome as a Product Manager
No matter how far into your career you might be, you’re never too old for imposter syndrome to make an appearance. Imposter syndrome is a feeling of inadequacy that persists despite the evident success, according to Harvard Business Review. ‘Imposters’ suffer from chronic self-doubt and a sense of intellectual fraud that override their feelings of success or external proof of their competence. Sound familiar?
So, to level the playing field. Even after years into my career as a product leader and founder, every so often, I too suffer from feeling like an imposter. We sometimes need to make decisions with imperfect information. Despite years of experience in this field, it still feels like I am taking risks as I lead LIKE.TG into the unknown.
For example, with a recent project, the data wasn’t playing out the way we expected. We had to decide whether to adjust or stand pat, with no clear “right” answer in front of us. As an expert, I should know how to do all this. However, at that moment, I felt like an imposter. However, I’m not — and neither are you.
hbspt.cta.load(3434168, '57ff7e42-ccfa-4d9e-b5be-8a0f6ba69363', {});
Why Product Managers are More Susceptible to Imposter Syndrome
Product managers (PM) are particularly vulnerable to experiencing imposter syndrome. The nature of our profession is nebulous. There a few reasons why product managers might be more susceptible to the feeling.
First, no one gets a degree in “product management.” You don’t train for it. There’s no set path to becoming one. There also isn’t a universal definition of success for product managers. With no pedigree or success validation, it’s natural to feel like an imposter.
Colleagues also look to their product managers to have all the answers. Of course, we don’t have them all—nobody does. But we’re expected to know just enough about everything that we can speak intelligently and have an opinion on nearly every subject. It’s important for our role. This creates very high expectations, which plant the seeds of doubt in our minds.
Product managers also wield power in their organization, even if it’s not always reflected in the org chart. We have an awesome job to decide what’s in and what’s out. Others have input, but view us as the gatekeeper. Unfortunately, that puts a target for blame if things don’t succeed. This fear of letting people down compounds, so we start to second-guess ourselves.
With the weight of the product on our shoulders, we’re the ones to say “no” to various stakeholders. We’ll say no to customer ideas or inform the CEO that their pet project won’t make it onto the roadmap. All while wondering who decided we’re qualified to make that call?
hbspt.cta.load(3434168, '3f36d63f-fe4f-400d-ab83-a64b28767625', {"region":"na1"});
How I Overcame Imposter Syndrome (and How You Can Too)
There’s no magic bullet, but I have found a few things that helped me get over the hump.
1. Humanize your counterparts
Everyone is in the same boat. We’re all human and we all have fears that we have to push through. That means regardless of how much success or failures our peers have had, they’re still putting on their socks one at a time. By humanizing your counterparts, it takes away the fear and intimidation that people are inherently better or more qualified to do your job.
2. Opportunity always comes again
Once it’s done, it’s done. Once a decision is made and acted on, then that ship has sailed. If it works out, great! If it doesn’t work out, there will be another chance to make another decision again. At that point, I’ll have learned from this mistake and be even better. There’s always tomorrow.
3. Nobody knows everything
As disheartening as it is to realize, I will never have all the answers. Nobody knows everything. We’re all always operating with an incomplete data set and no guarantees. That’s not a defense to solely trust our gut and wing it. However, it does mean you need to move forward and believe that you’ve done enough homework to make an educated decision. Inaction due to uncertainty doesn’t breed innovation.
4. Embrace collaboration
Embrace collaboration. The lone wolf product visionary that trusts no one, issues proclamation, and finds success is exceedingly rare. Most successful PMs learn fast that leveraging the knowledge, experience, and instincts of others makes things a lot easier. Not only are you operating with more information, but the decisions you make aren’t yours alone. Moreover, when others are involved in the process, they’re less likely to be resistant to the final decision.
5. Use data to make decisions
Metrics matter. You can use data to make decisions and convince others to get on board. This is a valuable tool for PMs. Not everyone is going to trust you. They might have their preconceptions and biases that you’ll be challenged to sway. However, with an argument based on facts instead of feelings, it’s much easier to build consensus, not to mention instilling confidence that you’re on the right path.
hbspt.cta.load(3434168, '1f74539e-d4fc-4cb3-97c6-fd86de2bf62e', {});
6. Vulnerability shows you have humility
Honesty is the best policy. I prefer to be the person that is open and has good relationships with people versus the one who bulldozes their way through. No one likes a bully or a know-it-all. Don’t be afraid to tell people you’re not positive about something or are still seeking input from others. Others will appreciate if you expose your vulnerability, it shows you have humility.
What I’ve Learned from Overcoming Imposter Syndrome as a Product Manager
Everyone’s trying to figure it out, just like you. Once you realize and accept this, you can be much more empathetic to others. That forgiveness is contagious, and I’m certain will circle back to you.
The only way is to outgrow your doubts. It doesn’t happen overnight. But over time, as you have more successes under your belt and more positive experiences in your rearview, you begin feeling like you belong.
Download The Essentialist Product Manager ➜ hbspt.cta.load(3434168, 'be753440-dc4d-40c5-9808-cad744d00a28', {});
It’s hard to do. But, try to stop caring about what other people think. When you’re confident in your abilities, you know you’re doing good work, and are treating people well then it becomes second nature. Now with all that free time you’ve created for yourself, you can do the fun stuff.
You don’t need that kind of stress. I’ve met plenty of older, successful people that are still racked with worry. Despite all they’ve accomplished, they can’t be content and convinced of their abilities. To them I say, “Relax, you’ve made it this far, and it wasn’t by accident.” Typically, this industry doesn’t put up with underperformers, so if you’ve made progress in your career, then you’re doing something right.
Let your guard down. People can tell when you’re forcing it, so don’t bother putting on airs. You are who you are, and you’ll do a good job or you won’t. Have humility, take the time to figure things out based on the input of others, and have faith that you’ll make the best decisions you can.
You can’t lead or even garner the respect of your development team, you have to believe in yourself. Not unreasonably or unwaveringly, but with general faith in your competence and abilities. Without it, no one’s going to have your back or want to follow you into battle.
Conclusion
Don’t let your insecurities hold you back! If your team didn’t think you could do the job, they wouldn’t work with you. Your requests for help are appreciated and not annoying.
Imposter syndrome is real and unhelpful to your career. Moreover, you can beat it. We’ve all been there. When you make mistakes, you’ll learn from them and be better for it.
Using Net Promoter Score to Guide Your Product Roadmap
Magoosh, an online test prep company based in Berkeley, California, calls Net Promoter Score their “reliable referral indicator.” And it is. But that’s not all it is. Although many people think of NPS as a customer success or support metric, product developers in innovative companies, like Magoosh and so many others, are using it to help guide their product roadmaps.
What does NPS guide them towards? Aligning product around users’ desired outcomes.
“At Magoosh, NPS is one of the most important metrics we track – it helps us determine not only whether students like our customer service and user interface, but also how well our products prepare students for their exams.” – Peter Poer, Director – Product Content
How Product Teams are Using NPS to Build Better Products Better Experiences
We often see product teams using NPS to track customer happiness (it’s a lean way to get a constant stream of customer sentiment). But, it’s also incredibly useful for helping to prioritize improvements and allocate resources. As Jason Lemkin of SaaStr says – “it is the one metric that keeps SaaS companies honest.”
Let’s say your NPS dips. Now what?
When NPS alerts you that there is a problem, the qualitative feedback that NPS responders offer can often tell you what the issues are. But, figuring out exactly what went wrong is one thing – finding the best way to solve it for customer happiness is another challenge altogether.
Use A/B Testing with NPS
This is where Magoosh, a test prep company, brought in A/B testing. They’d identified a falling-off point for their scores after students took the actual GMAT test. Looking into why, they found that passive and detractor students complained that their actual scores were lower than their practice test scores.
“Our algorithm was telling students to expect one score, but for some, their official reports were coming back lower – obviously a frustrating experience.”
The solution was to fix their score prediction algorithm to be more accurate – but they hesitated: Would it be more frustrating for students to get lower scores on their practice tests, or disappointing scores on the actual tests?
Their approach to solving this problem was to use A/B testing to, essentially, optimize for NPS.
They deployed the updated algorithm to half of the GMAT students and kept the other half on the previous algorithm. They were able to ask the NPS question and get feedback from currently studying students in real-time, instead of waiting to ask months later after students had taken take their exams and received their results.
“Suddenly, NPS had a new use case for us – as a powerful, agile product tool.”
Magoosh discovered that the more accurate algorithm had no effect on student satisfaction while studying with Magoosh, which allowed them to roll out the change to all students more quickly.
The results: Students from the A/B test who studied with the updated algorithm had their NPS jump 9 points after they completed their exams.
Magoosh used NPS data as an agile tool to shape the evolution of their product, prioritize updates, and act as a compass for their product roadmap.
hbspt.cta.load(3434168, '3f36d63f-fe4f-400d-ab83-a64b28767625', {"region":"na1"});
Effectively Use Qualitative Data for Product Dev
The NPS survey asks for qualitative feedback – the “why” behind the number. But there are right ways and wrong ways to use the ‘why’ data you get. And, if not used correctly, you can waste a lot of your product team’s time chasing the wrong leads.
Segment by Promoter, Passive, Detractor
First, you’ve got to understand where your “why”s are coming from. Promoters? Passives? Detractors?
Promoters will tell you what you’re getting right, and maybe, sometimes, what they’d like to see improved. Take their feedback very seriously, because they are your best customers, your target audience, the whole reason you’re sitting in your chair, gainfully employed.
Passives and Detractors can be a mixed bag, and here’s why: Some of these Passives and Detractors are not your ideal customers, or target clients. Some of them are just in the wrong place, using the wrong product for their needs. Be cautious about taking their “why”s as directives, you may make your product a worse fit for your Promoters and waste time and money doing so.
However, most Passives and Detractors are people who want to love your product. And they graciously contributed their time to telling you what you can do to make their experiences better.
Pay attention.
Be sure to follow-up with them and thank them all, because they’re doing you a big favor.
Segment responses by key user properties
Different categories of users have different needs and will experience your company in slightly different ways. You can segment NPS by any property that you have on your users – think about your business drivers. An Enterprise user may have a higher LTV than a Pro plan user. Allocate resources accordingly.
Track themes in the feedback
Keep score of trends in your feedback, and once you’ve identified a problem experienced by many, A/B test your solution.
It is a bit easier to filter and analyze trends with tagging, which gives some structure to qualitative feedback. You can use tags to track common themes related to your customer’s experience of your product or app — such as features, usability, support, pricing, performance.
Conduct Additional Research with NPS
NPS can help product development teams most when supported with deeper research, and deeper research can be facilitated by NPS segmentation. Hubspot’s product managers, for example, reach out to select NPS survey respondents to investigate further.. In one instance, they found that a mobile app they had created wasn’t getting as many recommendations as they’d hoped, so Hubspot reached out to a subset of users who had a high NPS for the desktop version, but a low score for the app version, to locate the disconnect.
Their top tip for reaching out to people is a good one: “Make it clear this request is coming from the product team.”
Customers are contacted by a lot of departments – sales, customer service, marketing. But when a call for help comes from the people making the product, it sends a strong message that your company is deeply invested in their success. You’ll get a higher response rate, and very likely, rich feedback.
And Don’t Forget to Share
Net Promoter Score isn’t just a “customer service” thing, or even a “product development” tool – it’s a tool every team can use to do what they do better. But, sometimes, data stays stuck within the product team, or within customer service. Don’t be afraid to take the lead and close the loop! Pass that data around to other teams. Pass promoters to marketing or sales. You have a wealth of data at your fingertips – don’t forget to share.
About the Author
Jessica Pfeifer is Co-founder and Chief Customer Officer at Wootric. Jessica has onboarded and advised more than 200 companies on effective use of the Net Promoter System. Prior to co-founding Wootric, Jessica spent six years growing brands at The Clorox Company. She also spent five years in China leading customer experience management initiatives for Aon Hewitt. Jessica holds a BA from Yale University and an MBA from Harvard Business School.
Effective Use of Product Roadmap Software to Align Your Product Strategy
What drives product professionals? They are driven with a hyperfocus on doing things that matter. Product professionals talk to customers and stakeholders to understand what’s important to them. They unpack their pain points to get to the root cause. They know the importance of a prioritization strategy and seek out opportunities to improve upon it.
We conduct customer research and stakeholder alignment so we can figure out what matters. Then we identify what we can do in our products that make an impact, be it on the lives of our customers, the growth of the user base, or the bottom line of the business.
However, we usually have far more ideas and options than bandwidth and resources. Thus, we realize a real need for prioritization, ranking and sorting, and culling the list. We can then choose a few items worthy of making the product roadmap rise to the top.
hbspt.cta.load(3434168, '3f36d63f-fe4f-400d-ab83-a64b28767625', {"region":"na1"});
The Downsides of Prioritization Frameworks
Because a prioritization strategy is of crucial importance to any product’s success, many different methods exist. Dozens upon dozens of frameworks stand ready for product teams looking for a new way to figure out the best ideas to pursue first, from buy-a-feature to MoSCoW analysis.
These frameworks aim to maximize windows of opportunity and optimize product development. It’s a testament to just how tricky, and complex a prioritization strategy can be.
Not only do these frameworks have lots of different names and acronyms, but they also require varied inputs. Some rely heavily on customer surveys, while others need a well-structured strategy or clear key performance indicators (KPIs).
While these tools often help, there’s an inherent risk to them as well. Product managers may feel forced to ignore critical data points due to the limits of the overall framework.
Product managers face limits due to the lack of a solid strategy. Their strategy should align stakeholders on a consensus moving forward. That must be in place well before plugging numbers into a framework. How else can you assess the significance of any item on the business making progress toward its goals?
IMPACT sets the stage for better prioritization conversations, moving the team past the “why” and focusing on specific trade-offs and expected outcomes.
Watch our webinar on IMPACT:
Applying an IMPACT Prioritization Strategy
As I’ve covered in many other blog posts, webinars, and our free ebook, IMPACT is a mindset for ensuring you’re doing things that matter. And there’s no domain where that matters more than prioritization.
So let’s run through the six elements of IMPACT and see how they relate to this essential aspect of product management:
Interesting
Not all problems are created equal. Framing and Context provide stakeholders with an idea of how pressing the issue is. Product management must act as a storyteller to engage their colleagues instead of just giving a dry recounting of the facts.
Folks get excited and influence how things get ranked. At this stage, the solution must take a backseat to the prevalence and significance of the problem.
Meaningful
The problems you opt to solve must both move the business forward and provide customer value. You can’t do either without an agreed-upon vision and strategy as well as a quantifiable benefit to the customer.
People
The focus must remain squarely on the customers, in this case, how many benefits and how significant is the improvement, which creates an apples-to-apples comparison and shifts distractions and edge cases to the parking lot.
Actionable
Prioritization must consider the realistic chances of solving the problem. Putting something impossible at the top of the queue—despite its possible value—wastes everyone’s time. That requires a little homework with engineering to consider feasibility and level of effort to ensure a balance between resource allocation and weight.
Clear
It’s tough to consider and adequately rank potential development items without a comprehensive understanding of the problem. Don’t prioritize things until the research is complete and the ideal solution is already in hand.
Testable
How will you validate that each prioritized item worked once it ships? Without a measurable definition of success, no one knows if it was worth it or if similar projects warrant resource allocation in the future.
Did you solve the problem? Is the value clear to end-users and prospects? User feedback confirms those assumptions—or sends you back to the drawing board—so the sooner they chime in, the better.
Download IMPACT ➜ hbspt.cta.load(3434168, '76387af0-7ef4-49da-8b36-28e99e4f5ba3', {"region":"na1"});
An IMPACT Prioritization Strategy in Action
For an additional lens incorporating IMPACT into a prioritization strategy, you can rank each item being considered based on the six tenets of IMPACT. For each of those six pillars, the team can rate each item on a five-point scale.
When evaluating a potential development item for “People,” for example, it might look like this:
1 – This only helps a minimal number of users in our target market.
3 – This allows lots of users with a particular characteristic/within a specific market segment.
5 – Everyone reaps significant benefits, and it expands the pool of potential customers.
Each item’s IMPACT is an objective countermeasure to the inertia that plague prioritization. The goal is to make the most of each development cycle, and the work with the most significant IMPACT is the work worth doing first.
To learn more about how IMPACT can influence this and other aspects of product management, download the free ebook today!
Finding Your True Career IMPACT Within the Product Field
Product professionals get paid to manage products and services. Delighting customers and creating innovative solutions for their problems dictates our priorities. But this single-minded focus on helping others often leads to a lack of focus on ourselves and our career impact in the product field.
And, unlike our products, no one’s getting paid to manage our careers on our behalf. Without intentional and thoughtful strategizing, years and decades can roll by, shifting and stalking our career trajectories while we worry about the success of others.
Applying the IMPACT mindset to your career can help keep that career impact trajectory on track by ensuring each move you make gets you closer to where you want to go.
From Individual Contributor to Director of Product➜ hbspt.cta.load(3434168, '9110b373-1b93-491b-8f83-5fc4b63b4b89', {"useNewLoader":"true","region":"na1"});
Being a Selfless Generalist is a Good Thing
A selfless approach based on customer empathy and satisfying stakeholders is an asset on the job, but less so for ourselves. We suffer from imposter syndrome and deprecate our value because, as generalists, we don’t command the same respect and awe as our more specialized coworkers.
But our selfless generalist approach is a superpower in its own right. Seeing the big-picture vision and possessing versatility enables product managers to impact, even when the spotlight falls on others instead. We check our egos at the door because the job demands it, and we don’t want a blindspot to punish the customers we care about.
Though it may not grab as many headlines or turn us into “influencers” in our respective industries, it builds the proper habits and work ethic to succeed in our current roles… and our next ones. Unfortunately, this means a scant opportunity to promote ourselves leads to personal “brands” that seldom extend beyond our companies’ walls (physical or virtual). Thus comes fewer opportunities to be “discovered” or headhunted or recruited as we continue operating backstage and behind the scenes.
Variety is the Spice of Life and the Bane of Product Management Careers
Anyone in product for a few years quickly notices no fixed definition of product management from one company to another. Some view Product as an equal peer to Marketing, Sales, and Engineering, while others tuck it away under a VP of Product Marketing or a CTO.
One organization may crown us “CEO of the Product” while another views us as an annoying check on runaway innovation. There appears to be a lack of shared understanding of what Product has to offer and why it’s so necessary. But the net result is seemingly random locations on organization charts, daily duties that differ significantly from one company to another, and product managers hailing from many walks of life.
The diversity presents challenges when attempting to:
Identify growth opportunities and spot which areas you must improve upon.
Translate a written job description into what it would mean for your career aspirations and how it maps to your current experience.
Tailor your resume, cover letter, and personal pitch to fit a particular job opportunity.
Download Developing a Product Team Checklist ➜ hbspt.cta.load(3434168, 'd8abf101-87a4-49aa-b909-2dcb3743fb8b', {"region":"na1"});
Putting IMPACT to work for your career
The IMPACT approach can help you optimize your career impact by assessing yourself in order to improve your career prospects and how you position yourself when you’re actually on the hunt for a new gig.
Optimize yourself with IMPACT
Whether you’re desperate to change companies, are angling for a promotion, or want to be the best you can be, IMPACT provides a structure for identifying your strengths and weaknesses while identifying areas to work on.
Interesting
Product managers need an exciting story. How you got to your current role, the career path you took, and where you’d like to go are essential to shaping how others view you. Resumes list the jobs, the degrees, and a few details in bullet points but don’t always recount a compelling story.
In a vacuum, your resume or LinkedIn profile might leave people with more questions than answers:
Why did you leave Microsoft for some startup that failed?
Why did you quit your job at a unicorn and throw in with a medium-sized firm?
What made you stay at the same company in the same role for six years?
How come you were once a Director, but now you’re a Senior PM?
Why did you bounce around between product marketing and product management?
To you, those moves all make sense, given the full context of your life and career. But job titles alone don’t do your narrative justice, ergo the need for a story that weaves them together. Connect the dots, find themes and common threads, and spin a tale that leaves others wondering what the next chapter holds in store.
Meaningful
Product managers do a lot of different things, many of them decidedly necessary. Listing out your responsibilities conveys competence with these tasks and obligations but camouflages your most impactful work.
Why you did those things and how you prioritized them is far more relevant. What did those accomplishments mean to you? To your company? To your users and customers?
When reviewing your experience, the emphasis must be on how they solved pain points and helped the company reach its overall impact goals.
People
A product manager’s relationships and interactions with coworkers are fundamental to their success. Those soft skills may not be measurable, but they are essential traits of your current future employer’s values.
Are you a good teammate that people enjoy working with? Do you make life easier and better for your colleagues? Are you a great mentor or a devoted protégé?
Those skills also come into play when interacting with customers. Can you speak in a language they understand and connect with them where they’re at? Can you engage them in deeper conversations to uncover the root issues and not just the surface-level gripes and wish lists?
Talent, intelligence, and creativity aren’t enough for a successful run in Product. You need to be a people person, too.
Actionable
When listing accomplishments, it’s important to deviate from the laundry-list approach and instead emphasize anecdotes or success stories where you either took action or set the stage for stakeholders to do so. You need to explain beyond merely discussing the completion of a task and what you did with the results.
You didn’t just “survey users,” you used that survey data to make recommendations, and one of those recommendations improved a KPI or led to a big deal, which better illustrates the meaningful impact of those actions, not that you just took them.
Clear
Keep things short and sweet while focusing on real-world examples of how your accomplishments made an impact. Showing off your skills and touting what they’ve done for you in the past are both keys to convincing folks you’re worth adding to their team.
Did you bridge gaps and build consensus by creating clarity among stakeholders. Have you inspired the masses with your oratorical prowess? Did you slice and dice the data and create dazzling visuals or unignorable metrics that won people over?
Testable
The dull, repeatable, everyday elements of your job aren’t the best measures of your competency. You need to get uncomfortable in an unfamiliar situation before knowing if you’re up to the challenge.
Push yourself to try new things, learn new skills, and dive into new areas of interest. Measure your faculty with this new material and see if you’ve got the resilience to power through when things get tricky.
Watch the full webinar below:
Putting IMPACT Into Action On a Job Hunt
With your elevator pitch nailed, the next part of advancing your career is assessing new opportunities. Once again, IMPACT can help by weeding out postings that won’t be a great fit while zeroing in on the good ones.
Job descriptions aren’t just ads; they’re problem statements you’ve yet to unpack.
What problem is this company trying to solve?
Where can someone add value and make an impact?
Are they mentioning customers and data?
Which verbs do they use?
Are they super specific in what they’re looking for or searching for an athlete to grow into the position and evolve with it over time?
Of course, what they say they want isn’t always what they need (or want), but it is a sneak preview of how they view product management today. It might be wrong and negotiable, but it provides a good glimpse of their current mindset.
With this as a starting point—and the remainder of the interviewing process as a series of additional opportunities for further digging—you can better ascertain the expectations for the role, your fit for the opportunity, and whether it will provide you with enough chances to make a true career impact. You want a job where you’re motivated to succeed, not just happy to collect the paycheck.
A Position with Purpose
The product offers us the opportunities to change lives, fuel businesses, and transform organizations. The problems we solve may be trivial or life-changing, but they all have the chance to impact our product’s users and customers.
Finding impactful opportunities throughout our career means more than just a job we enjoy or a product we’re passionate about. It gives our entire lives purpose and adds to the story of our career, adding new chapters with every step we take.
To learn more about how IMPACT can help with your career and other dimensions of product management, download the free ebook today.
hbspt.cta.load(3434168, '76387af0-7ef4-49da-8b36-28e99e4f5ba3', {"region":"na1"});
Conduct Better Roadmap Communication with Shared Legends
Every individual has a unique way they perceive and interact with the world around them. Recent reports claim that diverse organizations outperform their competitors by 35%, according to a recent report by McKinsey Company. The report also concluded that gender-diverse organizations outperform their nearest competitor by 15%. McKinsey Company’s report proves that product managers need to create an equitable user experience for their customers.
Throughout life, we bring our preconceptions, biases, fluencies, capabilities to the table. As a consumer, that’s usually not a huge problem. We find ourselves judging our own experiences, purchases, and solutions. If a product doesn’t meet our needs, we can find something more suitable for our needs.
Of course, not all individuals have the freedom of choice. When your boss requests that you use the new ERP system, workplace etiquette requires you to follow up on the request. When the bus or subway, or train pulls up to the stop, we can’t request a different model that’s a better fit. We must do our jobs and get to our destinations.
So what happens when that ERP system uses terminology employees don’t understand? And what if the bus doesn’t have a lift for our wheelchair?
Unfortunately, users may find themselves in a precarious situation due to decisions made by a product team. Software that remains intuitive and self-explanatory to novice users remains the most accessible. Product managers who do not account for these may get left behind by a market inclined to buy a product from a fair organization.
What Is an Equitable User Experience?
You can’t expect to make everyone happy all of the time. Product managers know this self-evident truth quite well.
That’s why we define our target markets and user personas. Product managers understand that building a product that satisfies everyone remains impossible. Chasing after all those edge cases leads to ballooning costs and lengthy delays for increasingly diminishing returns.
Why is an equitable user experience important?
Our ability to dismiss different cohorts can drive us to whittle down our total addressable market. An effective manager who utilizes a product roadmapping tool to strategize with their product team maintains a viable product. Product managers ensure that the product supports the financial stability of the organization. Moreover, they rule out unlikely use cases and vertical markets that don’t align with our strategy.
As product managers, we have to make choices that narrow the usability of our products. These choices don’t end with unusual applications. A product manager’s decision can increase the degree of difficulty for usersProduct teams rarely set out to create a product for a small subsection of the population. Instead, we would like to provide our customers with the best product possible.
hbspt.cta.load(3434168, '3f36d63f-fe4f-400d-ab83-a64b28767625', {"region":"na1"});
Why should you broaden the scope of your product?
Understanding the scope of your product influences the downstream decisions. As product managers, we understand the importance of thinking about who out there could use our product. When we do not broaden our market share, we isolate many subsections of society.
We often don’t realize how limiting those decisions might be. When we look around at our peers, our friends, our neighborhoods, and our families, we only see a sliver of the full population. We design for the “average consumer, ”which remains a flawed concept. Product teams need to develop products for a range of physical, cognitive, sensory, cultural, and socioeconomic variances.
Furthermore, your product should create a fair user experience. Oftentimes product teams fail to solve use cases or accommodate everyone. A product’s financial viability may also cause issues. As a product manager, you might determine that costs limit your ability to create a full user-friendly experience.
Developing a More Equitable and Inclusive Product Experience
Brittany Edwards—digital product manager and co-founder of Incorp[HER]ated—believes product teams must think beyond the types of people they see in the office. Some of this comes with who we choose to hire into our product teams, to begin with.
“If you don’t have a diverse organization and you’re not sure about what you don’t know or aren’t ready to acknowledge it, then the research you do is where you’re comfortable,” Edwards said in a recent webinar on Product Management Trends.
Companies need to break free of this unintentional-yet-ingrained limited perspective. Product teams must make a concerted effort to venture beyond their comfort zones.
“It’s all about identifying who your customer base truly is,” Edwards said, “Really push the boundaries of your definition of your customer.”
Product teams set out to understand what their users find difficult within the context of the product experience. That means talking to people, conducting usability sessions, and adopting best practices. If you search for opportunities to improve, things can always get better.
Of course, this inclusiveness can only go so far while still being practical. “It’s okay to be somewhat exclusive,” Edwards continued. “But acknowledge that and the risks that are associated with it.”
Potential roadblocks towards inclusiveness.
With so many avenues to increase inclusivity, there’s no shame in using an ROI as part of your analysis. If you can increase your target market by a few percentage points, you don’t have to worry if it’s fair. Instead, view every effort as a net positive.
You need to expand your potential market by doing the right thing. You should work to ensure your “starting point” remains unbiased. Challenging assumptions and remaining thoughtful in the design process.
Yet this only happens when there is time, space, and permission given to think about these unconscious defaults. As a product manager, you need to unpack the processes that lead to exclusion in the first place.
Accommodations Get Used in Unexpected Ways
The American Disabilities Act has been shaping public life since 1990. Federal and state regulations mandate that buildings provide ease of access for those with disabilities.
These sets of regulations make life easier for those suffering from a wide range of physical and mental limitations. They’re not the only ones who benefit. Parents with strollers also use those ramps, as well as shoppers with arms full of groceries.
ADA-driven changes provide value to everyone who uses them. They’re also an important reminder that product decisions made to accommodate one part of the market can end up benefiting many more people.
Some product managers may view the inclusion-driven activity as a costly exercise. Yet, it can enhance the user experience for much broader swaths of customers. Providing an option to increase the text size can attract older users, as well as those who have vision problems.
Expand Your Product’s Horizons
Your inclusive design can sometimes cause more problems and slow down innovation. For example, your product team may have to add in speech-to-text interfaces or develop a VR system that has accessibility features for individuals with a disability.
However, every step taken to make your product more accessible increases its utility for a broader set of users, creating organic growth opportunities for your product. Consumers will continue purchasing from you if they feel that the product provides accessibility, as well as functionality. By innovating the accessibility of your products, you have the opportunity to push your competitors towards producing an equitable product.
Over time, inclusive design becomes routine. “What about this?” and “what about that?” become welcome questions during ideation, design, and development.
Take the next steps toward creating an equitable user experience by:
Hiring more diverse teams
Talking to a wider variety of customers and potential users
Creating space and time to hear about a broader set of concerns and issues
Ensuring usability tests include different ages, races, shapes, sizes, genders, sexualities, geographies, educational levels, income ranges, and physical and cognitive capabilities
Asking your teams what else can we do to make things simpler, more accessible, and friendlier to as many constituencies as possible
Inclusivity and equity are about more than paying lip service to vocal minorities or being politically correct. There are a billion people with disabilities. The LGBTQ community has $3.6 trillion in buying power. The U.S. population is more than 30% Black and Hispanic.
Lastly, it’s simply good business to broaden your target market, and the brands doing so are seeing positive returns on their commitments to this practice. Don’t be caught on the wrong side of history with a product designed to serve only a small array of society rather than a universal equitable user experience.
The Secret to Product Planning
The secret to product planning starts with “why.” In some cases, product planning focuses on what we’re building, completing, and what’s up next. The rationale for all that activity isn’t simply to cross things off the list or pump out new functionality. It’s about turning a vision into reality.
But connecting the dots between the activities of a particular product development team and the overarching corporate vision can be a bit of a stretch for those not steeped in the strategic exercises occurring at the top of the organization. How a particular widget maps back to a vision of “transforming the world of peer-to-peer finance” or “unlocking the potential of idle computing power” or whatever can be a heavy lift. To unlock the secret to product planning, product professionals need to develop a clear product vision.
Putting Vision into Context
In an ideal world, everyone should understand the organization’s overall vision. It’s beneficial to take a top-down approach. Breaking that vision down into smaller pieces becomes more relevant to different parts of the business. It’s not always easy to map the contents of an individual sprint. However, a high-level strategy for an entire company remains possible.
The significance of each element of the strategy increases stakeholder alignment. Alignment creates motivation and enthusiasm amongst the teams. They can now realize how their contributions impact the big picture. This increased fidelity must begin at the planning stages, creating the platform for ongoing alignment and teamwork.
At LIKE.TG, each engineering team has a vision. That aligns with the product vision, which in turn aligns with the company vision. Though there is no one secret to product planning, this concept comes close. It enables engineering teams to understand how the world looks different if they’re successful.
Planning for Outcomes While Preserving Accountability
Each squad understands its purpose and objectives. The squads remain grounded on a shared understanding of what success looks like to them. Boiling down grand sweeping statements and visions to something tangible is key to bridging that gap.
Each member should answer the question: “What will our customers be able to do tomorrow that they can’t do today?” This very concrete, specific ideal guides their actions without being too prescriptive.
For example, it might be that customers can now automate more of their daily updates. The update doesn’t spell out precisely what that might look like or how it will get built. However, the vision is crystal clear. The product manager can then fill in more details. Consequently, delivering value is more important than a list of features.
That value must also be measurable to ensure the team achieves its goal of executing its vision. Alignment around how we know our customers’ lives got better is just as crucial as intending to improve things. That shared definition of success keeps everyone pointed in the same direction. Moreover, it creates a benchmark for ongoing, measurable refinement.
Finding the Sweet Spot
While strategic thinking and keeping everything in perspective are product managers’ strong suits, that’s not always the forte for everyone in the organization. They may not have the impetus or motivation to do so, and they may also lack the information and context even if they did.
Therefore it’s up to product managers to determine the right level of vision required to give everyone enough autonomy to move forward without overwhelming them. This task only becomes more difficult as the scale of the vision expands thanks to growth.
Creating a shared vision
For example, at LIKE.TG, our vision is to help companies accelerate product outcomes.
By presenting a shared vision and securing buy-in, the product calibrates the squad to be on the same page. Presenting roadmaps tailored to the audience in question provides a helpful resource to paint this picture as well.
That’s why we keep narrowing things down. We know this team in particular’s contribution to accelerating product outcomes centers on collaboration within the application. We briefly explain how collaboration contributes to the vision, giving product development further insight into the purpose of their work and not just the “what.”
Shrinking the view and scope of things isn’t typically how the product discusses vision, but departing from grand narratives and concentrating on specifics is what the implementation teams need to succeed. Like with IMPACT, it conveys what’s meaningful about the work, giving the team a better picture of how their individual and team efforts plug into the larger strategic objectives and customer experience. It turns abstract platitudes into concrete action plans and tasks.
Download Strategic Project Alignment in an Agile World ➜ hbspt.cta.load(3434168, 'bfb5032e-5746-4c05-9f2a-54b36ba0e871', {"useNewLoader":"true","region":"na1"});
Planning for the Future Without Becoming a Feature Factory
Company missions rarely change. Visions for the business typically extend five or ten years into the future. And strategies tend to cover the next year or two. Things get more specific the closer they are to the present.
But while missions and visions are vague, strategies and roadmaps tend to get more detailed out of necessity. Things can’t remain fuzzy once it’s time to build stuff, and that granularity helps teams plan accordingly and deliver functionality that adds customer value.
However, one shouldn’t confuse increased specificity with rigidity. The secret to product planning is to remain vision-driven and customer-centric. Product teams should stay flexible at every stage of the product planning process. Our product vision gets more precise as we continually learn more about our customers, their needs, and the overall market dynamics.
That’s where a roadmap based on themes versus specific features comes in. We’re all aligned about what areas we’re focusing on and our goals for each effort, but there’s still plenty of wiggle room on the details right up until implementation kicks off.
Maintaining Excitement and Energy.
Building products is still a job, and work remains an obligation versus a choice for most. However, imbuing the team with a sense of purpose can elevate the team above the daily grind and get them pumped up for what they can achieve.
By continuing to build what customers need and not just the promises in an outdated vision, strategy, or roadmap, we keep that joy of delighting customers close to the surface. We know we’re prioritizing what matters and spending our cycles on enhancements to the product experience that genuinely make a positive difference. And we won’t just build things because months or years ago, we happened to say we would.
The process only works well with the suitable structures in place. A foundation built on increasingly relevant visions grounds the work in its purpose. Visual roadmaps tie each project, task, and sprint back to each level.
This transparency builds trust and alignment while leaving room for flexibility as situations change and conditions evolve. It doesn’t happen overnight, and each stakeholder might warm up and embrace this approach on their timeline. By creating a solid understanding of the process and delivering a relevant vision for each team member, the team has established a product plan everyone can get behind. The secret to product planning will continuously evolve.
hbspt.cta.load(3434168, '3be75db1-0d50-46dd-b222-ce0aa84f6b08', {"useNewLoader":"true","region":"na1"});
Can Product Squads Improve Your Agile Development Process?
At LIKE.TG, I frequently get questions about agile roadmap planning. How should you balance long-term strategic planning with short-term agility?
This was an especially hot topic on a recent webinar we hosted. I thought I’d elaborate on some of my answers in this post. Here are 3 questions on that topic I’d like to highlight.
1. How do you balance agile uncertainty with roadmap planning at a growing small or medium-sized company?
It’s important for product managers to not make the mistake of thinking that because they have a roadmap, they’re not agile. Those two concepts actually work in tandem. You need an agile roadmap to set the strategic goals for your company, but you still have a lot of freedom to move things around within those goals.
Download How Agile Product Managers Can Build Better Products ➜ hbspt.cta.load(3434168, 'b4eb5c0b-bf4b-4a7e-9b0a-75f92005c127', {});
There are a couple of points that I’ll make around this:
The first is that you should be doing continuous customer discovery and customer interviews. You should always be engaging with customers in order to find the big problems worth solving. And when you match customer problems up with the strategic goals that you’ve set for your organization, it will point you in the right direction in terms of which features to build.
It’s important to remember that you’re not necessarily putting narrow features and tasks on the roadmap. Instead, you’re bubbling those up to make the roadmap very high-level.
You need to be looking at big themes that will help you move the needle in problem areas that your customers have. Think about the jobs your customers need to get done. Remember, your agile roadmap helps you communicate the strategy. When you keep your roadmap high-level, you maintain a lot of flexibility as a product manager to move features in and out of the backlog in order to accomplish your goals.
The second point I want to make is that you should be reprioritizing all the time. Reprioritize your backlog and your roadmap, especially in the long-term, because things change and different competitive pressures come up. Don’t lock in timelines that are too long, or your stakeholders will feel like you’re making commitments and they’ll expect you to deliver.
[Free book] Backlog Refinement: How to Prioritize What Matters ➜ hbspt.cta.load(3434168, 'ba6d6ffb-c21a-41c0-8f7e-7f79e553dae1', {});
I think those two points are really important — doing continuous customer discovery and constantly reprioritizing features. That way you can ensure your agile process is really working for you. You don’t want to find yourself in a position where you’re throwing features into the development queue that was decided on twelve months ago. Those features may or may not be the right things to do today.
And there’s one more thing I want to touch on — this idea of using a Kanban-style roadmap. The Kanban methodology has become pretty popular because it lets you organize the roadmap into different buckets — planned, doing, done, etc. — without committing to specific deadlines.
With a Kanban roadmap, you can designate things that you might want to be doing in the future, but you’re not quite sure about yet. You can distinguish the things that are a little bit fuzzy from the things that you’ve already committed to for the short term.
I think that in a small or mid-size organization, Kanban is a great way to avoid making the mistake of locking in an inflexible,12-month roadmap that may or may not end up being the right course of action. And, of course, it should also be mixed in with continuous customer discovery and reprioritization.
2. How far out should you plan your roadmap? How do you properly set expectations with stakeholders that plans will change?
I think it depends. The appropriate timeframe for your roadmap depends on the kind of organization you have, the type of product you have, and where your product is in its lifecycle. If it’s an early-stage product, your roadmap needs to be very short-term. You simply don’t have enough insight into what the right things to build are, so your roadmap needs to be very flexible.
On the other hand, if you have a product that is five or six years into its lifecycle, your planning horizon needs to be much longer. So, again, it really depends on product and company maturity, but at LIKE.TG, the most common roadmap time horizon our customers use is about a year.
Many organizations are moving to an agile planning approach, and that makes it less likely that the things you’re putting on your roadmap for six or nine months from now are solid — and that presents challenges for product managers.
We hear from a lot of product managers who feel that creating a one-year roadmap means setting unreasonable expectations among their stakeholders. And that’s really a caveat here — you have to communicate to your stakeholders that the roadmap will change.
One of the ways that you can do that is by bringing your roadmap up a level. Again, the roadmap should not be simply a list of features or a backlog. The roadmap should be tied to strategic themes. So rather than listing out specific features or tasks that need to be accomplished, roll those up into larger themes and communicate the roadmap at the theme level.
A theme ties back to strategy. For example, if your product is an e-commerce product and you want to reduce the rate of shopping cart abandonment — i.e. you want to improve the number of customers who are actually making purchases — that could become a theme. Now, the exact features that you create in order to accomplish that goal, or that theme, may change.
You also may not really know the effort level behind the features you’re considering. As you get closer to building them and you estimate the stories, it will become more clear what that effort level is. Then you can make trade-off decisions about which items will best accomplish your goals.
hbspt.cta.load(3434168, '3f36d63f-fe4f-400d-ab83-a64b28767625', {"region":"na1"});
So those are my recommendations — that you manage stakeholder expectations that the plan will change and that you bring the roadmap up a level. As a product manager, you have a lot of flexibility in what you can accomplish as long as you don’t get locked into building a specific feature set.
3. How do you adjust when you have roadmaps for a racehorse but realize you’re actually riding a mule?
I love that question! I think a lot of us have been there, and I think it’s just the nature of things.
As product managers, we know what the path is — we have the vision for the product. But sometimes things don’t move as quickly as we want them to. I think setting up those longer-term strategic goals is the right way to safeguard against unexpected bumps in the road.
And there’s no quick fix here other than to just stay on the path. As long as the path fits in with those strategic goals, you’ll eventually get there. Having that long-term strategic perspective will make it easier to say, “Yes, we are going to do that, just not yet.”
I also think that this is where the concept of an MVP comes into play. Not every feature is important, and a lot of the things that you have on your roadmap, especially if you thought them up in the conference room, may not be the right things to build in the first place.
I’ve found that I can often satisfy customers and give them a lot of value by building only 50% of what I thought they needed to have — and I’m constantly surprised by that. If you’re solving one key problem for them, they’ll buy and they’ll be happy, even though you may not have given them everything that was on the initial roadmap.
How a Public Roadmap is Helping LIKE.TG Customer GOV.UK, and its Customers
A few years ago the UK government’s publicly available online information was spread out across hundreds of individual and disconnected websites. So the Government Digital Service (GDS), a department within UK’s Cabinet Office, set out to consolidate this information and make accessing it easier for the nation’s citizens and interested readers around the world.
The result was GOV.UK, a single point of online access to UK government information. This online hub, which receives 12 million visitors every week, describes itself as “the best place to find government services and information… simpler, clearer, faster” and has given itself the ongoing goal of “making government work for users.”
I spoke recently with Neil Williams, a founding member of GOV.UK’s product team and now head of the 140-employee GOV.UK team within GDS. We discussed Neil’s groundbreaking 2016 decision to help make the platform even more transparent and accountable by releasing a publicly available product roadmap.
Neil’s product management approach is fascinating and offers, I believe, some valuable insights for product managers in both the public and private sectors.
Jim Semick: You didn’t start out with a product roadmap for the GOV.UK platform. What was the catalyst that caused you to create one to map out and share your strategic vision for the website?
Neil Williams: For a long time during the development of the GOV.UK website, we didn’t believe we needed a roadmap because we were really just in ‘skirmish’ mode. We wanted to build something new that could replace all the existing government sites. Plus, in the early stages we were a small group. 14 people working very closely together on an alpha product.
I think what moved me to see the need for a roadmap was actually twofold. First, there was the increasing size and complexity of this thing we were creating. GOV.UK became much bigger and more complex. Our team eventually grew by 10x, from that initial 14 to a team of 140 that I manage today. And our stakeholders became more numerous with more than 330 government organizations publishing to the web via our platform.
As we grew more mature, and as groups began to work on different initiatives for the platform in parallel, we definitely needed a roadmap to document, track and share all of our plans and objectives and make sure we were all pulling in the same direction.
At the same time, it’s important to understand that a central part of the culture at GDS is transparency. You can see it on the posters in our offices and the stickers on our laptops: ‘Make things open, it makes things better.’ So the second reason we moved to a roadmap is that it just made sense to create an ongoing, open source of information where our colleagues and (later) the general public could come and see what we were working on at GOV.UK.
JS: That’s a great lead-in to my second question. Why you chose to make your GOV.UK product roadmap available to the public. Indeed, today anyone can view the roadmap at your Inside GOV.UK blog. This is a relatively uncommon move for product managers. What did you see as the benefit of a public roadmap?
Neil Williams: For most of my professional life now I’ve been a member of the civil service, and honesty is enshrined in our values. That matters a great deal to me and an ongoing theme in my career has been to help create more openness and transparency within government.
For example, many years ago I launched the first-ever blog by a UK Cabinet Minister and soon after became one of a handful of civil servants who started blogging about their work in the late 2000s. I’ve gone on to spend a lot of my career pushing departments within the UK government to be more open and engaging with the public, using the culture and tools of the internet.
Within GDS, I was pushing against an open door. We were set up as a new bit of the civil service with the express intent of being a strong center of digital culture and expertise – so all employees at the Government Digital Service blog about our work and anyone can check in with what we’re building and planning by visiting our public blogs, be that the main GDS blogor the blogfrom a given team – like Inside GOV.UK.
As GDS’s most mature product, GOV.UK was the first to start roadmapping across multiple teams and was first to go public with our roadmap – but the precedent of openness was already there (we code in the open, many of our backlogs are open, and like I said we blog by default).
And – most importantly – publicly posting our roadmap is perfectly aligned with the GDS mission, which is to make government work more efficiently for our citizens. You have to keep in mind that we are a public agency, funded by taxpayers rather than revenue from customers. Unlike products in the private sector, we aren’t driven by sales figures, active users, conversions or profit-and-loss.
Our users are the taxpayers who fund us, which makes them our most important stakeholders. Making government services better to meet their needs is our entire reason for existing. So as far as I’m concerned, we have to make this information readily available to the public – it’s a moral issue, as I see it, for us to be as transparent as possible to the users the website is there to serve about what we’re working on, and listen to their feedback.
JS: Okay, so that’s a great explanation of how a public roadmap benefits GOV.UK’s end users and other interested parties. Does making the roadmap public also provide benefits for you and your own team?
Neil Williams: Absolutely. It keeps us on our toes to have public oversight of what we’re doing.
Saying publicly what we think we’re going to do means we’re held to account, and if we get delayed for any reason we have to be ready to explain why. That’s good discipline, it keeps us honest.
It also keeps us focused. Everyone is watching — or at least can watch — and so any delay or change of plan is visible.
A second and related benefit I see in making our roadmap public is that we receive user feedback on it. The simple act of posting the roadmap online generates constructive challenge and valuable ideas from our government colleagues, and sometimes the public.
It also has the effect of heightening interest in GOV.UK and what’s coming next for the platform – including for prospective employees, who we obviously want to be excited about the work coming up here so they choose to come and join our team.
And, most simply, publishing the roadmap is far and away the most efficient way for us to keep all of our government colleagues around the country up-to-date on the progress of our platform. We have more than 3,000 admin users across the 330 organizations that make up the central UK government, and they are very widely distributed, which makes it difficult and costly to reach all of our stakeholders with every update.
Maintaining a public roadmap online, then, is just a more efficient way of communicating the ongoing plans and objectives of GOV.UK with everyone in the government.
JS: And finally, may I ask you about your experience using LIKE.TG to create your GOV.UK roadmap? Why did you choose our roadmap software and how has it worked for you?
Neil Williams: My first approach to building the GOV.UK roadmap was to use a static design tool and then output a PDF to share with my team and stakeholders. I published this roadmap monthly.
This was okay as far as it went. But it was laborious, and too static – each monthly issue was outdated within a few days after publishing because details were always changing. So we needed something more interactive and collaborative, easier to update and share.
Then I moved to an online collaboration tool, which served our needs perfectly while we were still completing the initial build and working on a small number of concurrent goals. But we outgrew that at the start of this financial year (April) when we started to need to show multiple streams of work, which teams were working on which things,interdependencies and so on.
The tool we were using was great for Kanban boards but wasn’t designed specifically for product roadmap creation, so it didn’t have the ability to allow me to show, for example, the same roadmap at the different levels of detail depending on the audience — such as the feature-level stuff, the group-level objectives, and the more strategic-level vision.
LIKE.TG allowed me to tell the GOV.UK story, setting out the narrative of what we’re doing next, with the right level of details for different audiences. And it made it easy to get it all set up very quickly compared to some of the other tools I tried.
Plus of course it has an option to share the roadmap via a hosted URL, which was top of the selection criteria for me! It’s working out well for us so far – and I’d encourage product teams everywhere to try going public with their roadmaps, what’s the worst that can happen?
Benefits of Roadmap Metrics
A tool is only helpful if people are using it. We’ve all got exercise equipment, cooking gadgets, or crafting supplies lying in corners and closets collecting dust and good intentions. There’s nothing wrong with those items, but they’re also not adding any value while they sit idle. Understanding the benefits of roadmap metrics can help align your product team. For this reason, tracking whether or not your roadmaps are being used can help guide your product team towards a shared vision.
Roadmaps add value when used regularly by coworkers and other stakeholders. But once you email or Slack a document, you have no idea if anyone even opened it a single time. The lack of visibility may have you wondering if anyone actually referred to it. There’s simply no way to measure, leaving you with doubts and uncertainty.
When the Ideal Meets Reality
Roadmaps intend to create and reinforce alignment across the organization. They give everyone a clear view of the direction of the product or project. They connect to the key themes, strategic goals, and intended outcomes of those efforts.
In a perfect world, individuals reviewing and referencing roadmaps would happen all the time. Roadmaps would be part of everyone’s daily or weekly routines. Yet far too often, roadmaps are glanced at briefly. Sometimes they may get ignored until an issue forces a second look.
If people aren’t looking at your roadmaps regularly and using them to guide their own work, they aren’t living up to their full potential. Even worse, some stakeholders might still be viewing old and outdated roadmaps without realizing it, making their plans based on false information.
Download Strategic Project Alignment in an Agile World ➜ hbspt.cta.load(3434168, 'bfb5032e-5746-4c05-9f2a-54b36ba0e871', {"useNewLoader":"true","region":"na1"});
Solving a Pervasive Problem
Using a purpose-built, cloud-based roadmapping tool such as LIKE.TG alleviates many of these issues. For one thing, as long as people are using the web viewer to see your roadmaps, you’ll know they’re always looking at the latest version.
Beyond this critical version control advantage, these tools can also provide product managers, scrum masters, project managers, and other roadmap authors with additional insights. We want to help you treat your roadmaps as a product. That means understanding if and how people are engaging with them. This is why we built roadmap Activity Metrics, so you can now see exactly how often your individuals view your roadmap each week.
Putting Roadmap Activity Metrics into Action
With this data, you’ll have a much better sense of whether your roadmaps are collecting digital dust or accessed regularly. Product Ops and project managers can track roadmap activity metrics just like other KPIs and metrics.
After an update is shared and communicated, roadmap authors can eyeball these metrics to ensure a corresponding spike in views occurred. If not, they’ll know they need to use other vehicles to prompt this action, from leveraging a company all-hands meeting to other tactics specifically tailored to engage critical stakeholders.
Additionally, roadmap owners can pursue a different course of action if roadmap activity metrics indicate that views are too low in between announced updates. Initiating open, frank discussions with various stakeholders and colleagues, you can investigate why they’re not viewing your roadmap more often.
Analyzing roadmap metrics may reveal a host of unknowns, from a general lack of awareness to missing information and context. These unknowns make the roadmap valuable to your product team and stakeholders. If the latter scenario turns out to be the case, you can create custom views of the roadmap for each of these audiences, ensuring it has the most relevant information.
Analyzing roadmap activity metrics can help you manage your product team better. By seeing the number of individuals who view your roadmap, you’ll be able to jump in and coach your team to socialize the roadmap’s contents and value better. It may also be an early indicator that their roadmap is flawed or missing something.
Another Measure of Success
Every business has many ways to measure its overall success, from revenues and profits to usage, adoption, and churn. But our internal processes don’t always have as many data points to track and put to use.
Your roadmap metrics deserve a spot on your organization’s Product Ops dashboard. These artifacts are too essential to ignore. Roadmap authors now have the power to evaluate their utilization and effectiveness.
Learn more about how roadmap activity metrics work in LIKE.TG or schedule a full demo today!
hbspt.cta.load(3434168, '9252db78-e0f2-4f64-b933-416e291c2422', {"useNewLoader":"true","region":"na1"});
Better Product Strategy Meetings in 5 Steps
Ah, a free exchange of ideas. Sounds nice, doesn’t it? Until you’ve got five stakeholders sitting in an enclosed space spitting out “Must Haves” like watermelon seeds in a county fair contest. Ideas are great, but a strategy everyone can agree on is better. How can you get from one extreme to the other? How can you improve your product strategy meetings?
Successful product strategy meetings don’t happen by accident — they require planning and expert execution. So here’s a 5-step formula to help make your meetings run more smoothly and effectively, and round up those maverick cats.
hbspt.cta.load(3434168, '1f74539e-d4fc-4cb3-97c6-fd86de2bf62e', {});
Step 1: Set one objective — just one — no cheating
Because a product strategy meeting is generally a high-level discussion, you can expect your attendees to come ready to brainstorm, pontificate, philosophize — even argue. This is all okay, even beneficial, as long as the discussion does not stray from your meeting’s single strategic objective.
Without an ultimate strategic focus, these meetings can quickly devolve from productive discussions about planning your product roadmap to heated debates about a specific feature. Or worse, they can devolve into several simultaneous arguments across the room, with attendees debating features, colors, deadlines, budgets, and other non-strategic details.
This is why it’s a good idea to set a single strategic objective for your meeting. Here are a few examples:
Achieving a specific revenue target for your product in the next fiscal year.
Increasing the number of users (including free-trial users) over the next 6 months.
Maintaining your current market position for the next two fiscal quarters.
Notice that these are “SMART” goals — specific, measurable, attainable, relevant, and time-bound.
Now, as soon as you open the meeting, you will want to communicate this objective with your attendees — and get their buy-in.
Establishing this strategic objective at the outset of the meeting will help ensure that you and the other attendees are able to quickly identify the moment the meeting gets off-topic, so you can steer it back on track.
And if your meeting does drift from its single strategic objective, you’ll be ready with Step 2…
Step 2: Pave paradise, and put up a parking lot for off-topic ideas
In a free-flowing stakeholder discussion about your product’s future, it is almost inevitable that the conversation will lead to ideas and suggestions that are valuable, but not relevant to your single strategic objective. What then?
These are the moments when you want to be able to say, “That’s a great idea… but a bit off-topic. Let’s park it for later.”
And the best way to do this is to actually have an idea parking lot on which you can jot down the idea and the person who proposed it.
Your idea parking lot can be a whiteboard on the wall or a freestanding flip board in the meeting room. You could also simply keep a piece of paper in front of you during the meeting — but ideally, the parking lot will be visible to everyone in the room at all times. Often if a person sees their idea captured in a visible place, with their name written beside it, they will feel validated as being heard.
Step 3: Leave your egos at the door, along with sharp objects and tuna fish sandwiches
Often a product strategy discussion will drift into controversial subjects…
“Should we even keep focusing on this part of the product? Our competitors have this segment of the market already.”
“Do any of our customers actually care about this functionality anymore? We’re spending a lot of development cycles on it, and no one seems to be using it.”
Addressing difficult topics like these can be invaluable to the long-term success of your product. But sometimes the participants in your meeting who have firsthand knowledge or data about these issues are uncomfortable sharing them in a meeting full of executives who outrank them, product managers who obviously care about the product, and developers who’ve built it.
This is why it’s a great idea to encourage open discussion about the product in these meetings — from anyone. Your product strategy meetings are by nature typically positive, forward-looking conversations. But you need to use these meetings to air everything related to your single strategic objective — good, bad, and ugly.
One great way to set this open discussion for your meeting culture is with a sign on the door — “You are entering an ego-free zone.”
Step 4: Be ready to defend your strategy with data
Of course, this culture that you want to create for your product strategy meetings — where everyone is encouraged to offer their thoughts, good or bad — does not mean that every opinion itself should be treated equally.
If you want to propose a specific strategic plan, you should be prepared to back up that plan with evidence — not merely your gut instinct.
A product strategy meeting can easily turn into a battle of opinions. And in a meeting where many of the attendees are executives who outrank you, it can be difficult to have the confidence to stand behind your strategic ideas if you can’t back them up with hard evidence.
Furthermore, executives often have a bias for data because they know that every decision represents a risk — and people are often more comfortable with risk if it has hard evidence supporting it.
Step 5: Communicate your agreed-upon strategy after the meeting
When you have achieved the ultimate goal of your meeting — an agreed-upon product strategy for you to begin driving — you will want to take one more step before digging into the execution.
Because people often hear things differently in meetings like these, it is a good idea to recap for everyone who participated exactly what the team agreed would be the product strategy.
And the best way to do this will be with a clear, plain-language recap — accompanied, ideally, by an early draft of your visual product roadmap.
Nobody trips and falls into successful product strategy meetings — you have to create them on purpose
If this formula doesn’t jive with your company culture, feel free to deviate and iterate. My problem-solving method of choice is to make a list of everything that might happen and what I’d like to have happened and draw up plans beforehand. As with everything, planning ahead is the key to success, even with challenges like competing ideas, strong opinions, and limited resources. You can still unite your stakeholders around a single strategic objective, and go from there.
6 Product Leadership Interview Questions and Answers
On behalf of the LIKE.TG team, we are excited and honored to share some exciting news. Along with the honor of getting certified as a Great Place to Work (May 2021—May 2022),we earned the recognition of Fortune’s 2021 Best (Small or Medium) Workplaces.
Although one of our team’s values is humility, I wanted to take a moment to say, “heck yeah!” Thank you to the entirety of the team for your efforts navigating this past year.
What Did This Year Look like for LIKE.TG?
Like many companies, we practically learned overnight how to manage our business differently with the onset of the pandemic. The process of placing our operating practices and guiding principles under a microscope allowed us to solidify what was working well and what we needed to improve.
In particular, we saw the need to be more intentional about how we build a great culture. LIKE.TG believes how employees act when nobody is looking defines company culture. We felt alignment become even more critical in a world where our team is all working remotely. We also know people want to work alongside people they trust.
Strong values alignment becomes even more critical as a company scales and growth accelerates. In the past year alone, our business doubled in size. We released several key product enhancements. Product organizations utilized these enhancements to help simplify the shipment of products.
What’s Our Secret Sauce?
So how did we win Fortune’s 2021 Best (Small or Medium) Workplaces over the ten thousand contending companies? We believe a key was really clarifying and subsequently living by those values that bind us.
LIKE.TG’s core values assist in recognition as one of Fortune’s great places to work.
Hustle: We’re passionate about what we’re doing. But we hustle to preserve time with our friends and family. We empower employees to own the outcome. We encourage them to want to win because it means we are making an impact as a whole.
Humility: We listen first and ask questions when we don’t have the answers. We approach interactions and problems with curiosity and adjust our course when needed.
Heart: We want our work to have meaning, and we care deeply for our team, our customers, and our society at large. We embrace the visible and invisible differences to create a place where people feel safe speaking plainly and being the best version of themselves.
“I’m really proud of how the team exemplifies Hustle, Humility, and Heart every day. We help our colleagues’ career paths grow and develop. I’ve loved getting to see team members get the chance to move into different teams and get promoted into new roles from a manager of customer success, becoming a product manager to a customer success manager, becoming a sales engineer. Seeing folks get the chance to spread their wings, try something new, and move forward is core to what I think Hustle, Humility, and Heart mean in our workplace.” – Diana Ciontea – Finance
“We work with real people. We’re not just numbers and jobs to be done. The team gets to know each other and spends time caring about each other’s interests, and there’s trust built there. I trust that my colleagues are putting in their heart, with humility and they’re hustling in everything they do that helps us remember that we’re all people behind the job.” – Nick Fields – Product management
[VIDEO on Heart Humility and Hustle]
Fostering Connection at LIKE.TG
After the Black Lives Matter protests, we came together as a company to openly share how people were feeling. It was particularly moving to hear people speak plainly about what this topic meant to them while also serving as a time to catalog our practices. These conversations inspired the creation of our diversity and inclusion task force. This cross-functional collaboration has spawned various initiatives, including mental health days, a fundraiser for disadvantaged children, and a fresh look at the hiring process.
LIKE.TG’s biannual “Fest.”
Another critical moment for our team was launching our first, all remote, teamwide gathering we call Fest. In the past, Fest represented a biannual event where in-office and remote coworkers would convene for social and educational activities. Activities included presentations from customers to lightning talks where employees volunteer to present on a topic of passion and trivia at a local brewery, to name a few. This event represented a great way to cultivate strong team alignment, especially since most of our team lives outside Santa Barbara. As we all know, large in-person gatherings weren’t on the agenda this past year, so we had to improvise.
The process of building a weeklong schedule to support a 100% remote Fest helped flesh out many of the lingering habits ingrained from in-office work that didn’t support remote workers. While we all look forward to a face-to-face Fest again, we believe the emphasis on learning how to do remote work well sets us up for longer-term success.
Inspired by feedback from our team, we have since launched a mentorship program and a Culture, Collaboration, and Connection (CCC) monthly meetup. At CCC, in a small group setting, we tackle various topics ranging from the company’s long-term strategy to learning more about each other’s interests outside of work.
Trust and Strategy at LIKE.TG
Some of us may have worked in lower trust or what some may call ‘political’ environments. People often expend unnecessary energy in the wrong areas. Also, those environments tend to stifle open communication among teams. We believe that the best ideas can come from anywhere. Consequently, it is incumbent upon our organization to ensure processes amplify and encourage the sharing of information.
A great example is how information our team gathers from customers finds its way into our product prioritization process. The bulk of our team is talking with our customers every day. Harnessing insights from these conversations is foundational to our strategy especially given how quickly the product management space evolves.
Trust, or a lack thereof, is something we know product managers often grapple with internally. Often, they feel frustrated conveying to stakeholders how and why things need prioritization. Ultimately, we see our role at LIKE.TG as helping our customers instill greater trust within their own organization.
“It feels like my input is valued here. We work hard, but we love the work we’re doing because we know it’s positively impacting on ourselves, our customers, and the world.” – Sierra Newell – Marketing
“I know when I come in, I can be my authentic self. I’m welcomed and valued for that. I can walk in the door and don’t have to be a different person. I can be who I am, and everyone respects and values me at ProductPlan. I can flourish and be happy and fulfilled because I can be myself at the end of the day. – Damon Navo – Customer Success
Final Thoughts on Fortune’s Great Places to Work
Being recognized as one of Fortune’s great places to work is a tremendous honor, especially in light of the challenges brought about over the past year. We also believe much of our success is still in front of us. We’re excited to continue our journey to help product organizations simplify the product life cycle and build organizational trust.
Check out our Careers Page if you are interested in a role at ProductPlan.
hbspt.cta.load(3434168, '4bc8dfae-deb7-4eb4-b82f-7f20e14b8f2f', {"region":"na1"});
What the 2016 DDoS Attack Can Teach Product Managers About Disaster Preparedness
Chances are you weren’t giving much thought to the global stability or security of the Internet on Friday, October 21, 2016. Even if you run an Internet-based business, it likely wasn’t a top concern. But it certainly was on that Friday! That was the day when, for a time, it seemed the Internet itself was at risk of catastrophic failure.
In case you’re reading this post several years after its publishing (which, thankfully, means the Internet is still functioning), here’s a quick refresher: October 21, 2016was the date we experienced what cybersecurity experts at the time deemed one of the largest and most sophisticated hacks ever on the Internet itself. The DDoS attack (a “distributed denial-of-service”) was generated when thousands of Internet-connected devices (digital cameras, DVRs, etc.) were infected with a malware called Mirai — significantly slowing web traffic and disrupting or even shutting down service for many of the world’s most popular websites.
Tweet This:
“Is your roadmap flexible enough to handle a disaster?”
Again, if you’re reading this several years from now, these sites include Hotmail, AltaVista, CompuServe and MySpace… just kidding. It actually affected sites like Amazon, Twitter, Spotify and PayPal.
Although all of the specific security measures and defense protocols taken to counteract this DDoS attack weren’tshared with the general public, it seems the companies responsible for the Internet’s backbone handled things as well as we could have hoped for.
Perhaps most relevant to our discussion here, the company responsible for the managed DNS infrastructure most affected by the attack — an organization called Dyn — seemed to have a disaster preparedness plan already in place for just such an event. Dyn’s plan included:
Technical countermeasures to stop, slow, or at least mitigate the damage
A real-time investigation to trace the attack back to its source
Real-time learning to help the company immediately develop and deploy new measures to strengthen the Internet’s defenses and prevent similar future attacks
An ongoing communications plan to keep the hack’s most affected businesses, law enforcement agencies, the media, and the public informed at all stages of the attack
What is Your Product Team’s Plan for a Disaster?
As damaging and concerning as that Internet DDoS attack was, it does present us with a silver lining. (See that? No cloud puns. You’re welcome.)
This hack serves as a great reminder of the need to review our own disaster prevention and disaster recovery plans — or, to create them for the first time.
So the question for you and your business is this: How would you handle a disaster that affected your product and your customers?
Do you have a plan in place that can be activated if your product experiences a failure or your company suffers a disaster such as flooding or a cyber hack? Are all of the necessary people in your organization preparedfor such an event? Will they know how to respond?
Tweet This:
“How would you handle a disaster that affected your product and your customers?”
And just as important, are you building preventative measures into your product itself? A strongdisaster response plan will help minimize the harm done to your company and customers in the event of unexpected emergency.
With this massive attack still in the news, this might be a great time for you and your product team to review your disaster preparedness protocols, or develop new ones, and to earn the needed buy-in from your stakeholders to build both disaster prevention and disaster recovery planning into your product roadmap.
Here are some suggestions.
Disaster Prevention (or Mitigation) for Product Managers
As a product manager you are under relentless pressure to add game-changing features to your product. But you need to balance your roadmap’s focus between those headline-grabbing features your stakeholders and customers demand… and the much less exciting but equally important components that will give your product stability, safety, and protection against disruption or failure.
Some examples of these to feature on your roadmap include:
Compliance and certification
Bringing your product into compliance with data regulations like HIPAA, or obtaining quality-assurance or security certification from standards bodies such as ISO can be a good idea. These certifications can help establish your company’s credibility with prospective customers. But they are also important for a more practical reason.
Gaining certification from these organizations can serve as a valuable proxy for determining that, yes, your product can withstand many forms of disaster — and either maintain normal operations or recover in a timely manner.
The right data backup infrastructure
If you’re running a SaaS (Software-as-a-Service) application, part of your product development needs to focus on how your customer data will be backed up. Willyou store iton a single server? Shouldyou maintain multiple copies of each customer’s data? Will you keep these copies in separate geographical locations to ensure redundancy? Will you encrypt this data while it’s at rest under your care?
And if you sell a software product that your customers download and maintain on premise, what responsibilities, if any, will you maintain for backing up their data? Will you have a recommended backup architecture for them to maintain? Will it include mirroring their data to an offsite cloud backup service?
To reference our earlier suggestion about certification and compliance, it’s worth noting that federal data laws like HIPAA and GLBA demand regulated businesses to safeguard their customers’ data. Among other measures, deploying a secure offsite backup solution is just one of those requirements. This is to ensure that if the company’s headquarters are affected by a power outage or fire, their customers’ data can still be recovered and accessed.
An appropriate level of fault-tolerance
Another important but unsexy component of your product roadmap should be a focus on setting up the right hardware to support your expected levels of traffic.
You will need to understand the volumes of traffic your product is likely to receive —how many simultaneous visitors, what features they will be using and how much bandwidth that usage will require to maintain a stable and acceptable user experience.
The hardware architecture you’ll need to support 1,000 customers will of course be very different from the hardware you’ll need to handle 1,000,000 customers.
For this reason, you might also want to campaign for a hardware architecture that is designed for faster and easier scalability. That way, if your product experiences the coolest of all “disasters” — overwhelmed with greater-than-expected customer usage — you will be able to quickly ramp up capacity to keep your customer enjoying a high-quality user experience.
Tweet This:
“Fault tolerance: not as sexy as a new feature, but still important for your roadmap.”
Of course, some of the suggestions we’re offering here might fall under the responsibility of your engineering team or some other department in your company — and not product management. That’s okay. The important thing is that you have these disaster prevention items on your mind and that they make it onto the product roadmap.
How about you? What disaster preparedness or recovery strategies has your company put into effect? Have they proven useful? Please share them here. These are the types of learnings we’d much rather gain by reading a blog post than from firsthand experience.
Product Management Trends You Should Act on Today
Tools, technology and talent to develop innovative new products are more abundant and accessible today than they’ve ever been.
Even the smallest, most cash-strapped companies have access to the code platforms, software applications, powerful new marketing tools, and engineering talent to help them turn their product visions into reality.
But the problem isn’t a lack of tools to design and build new products. Nor is it the dedication of product managers and their teams. Why, then, do companies and startups have challenges releasing winning products?
Ironically, one of the primary reasons is the very fact that there has been a proliferation in the tools and knowledge for making great products. Take mobile apps for example. Sophisticated infrastructure has been developed to help businesses quickly and inexpensively create apps. This has led to an explosion of new apps, which has in turn led to both increased competition among app-makers and an ever-increasing expectations among app users.
So if product managers can expect to contend with ever-more competitive offerings entering your market, what should they do? Our suggestion is to go back to the fundamental principle of product management: Find new ways to create value for your customers.
Here are some ideas to help you place this key focus — prioritizing customer value in all of your product decisions — front and center for your product strategies.
1. Create modular offerings for your products.
Obviously the days of the thick-client software products are numbered, if not already over. With the cloud and anywhere access, you can no longer expect to sell software applications that have to be downloaded, installed, and then manually upgraded and patched on specific machines.
But even if you’ve already moved to a cloud-based model, selling software-as-a-service, you need to continue finding innovative ways to appeal to new users, and to make your offering even more valuable for existing users.
One way is by making your cloud-based software products modular.
Salesforce.com, for example, offers multiple versions of its CRM tool — from a scaled-down platform at a price point that a solopreneur or very small business might find attractive, to a much more robust enterprise-level solution designed for large corporations.
But perhaps you sell a product — software or otherwise — that doesn’t lend itself to being scaled up or down as easily as a web-based CRM tool like Salesforce.com. That’s okay. You can still find creative ways to make portions of the product available to various subsets of your users, or even to new categories of user personas not interested in the rest of your offering.
Remember, the key here is creating and adding value for your customers.
hbspt.cta.load(3434168, '1f74539e-d4fc-4cb3-97c6-fd86de2bf62e', {});
2. Find relevant vendor partnerships to extend the value of your offering.
Think about your product not as a stand-alone tool or service, but rather as part of a larger solution for your customers. This is true especially if your company sells products to other businesses.
Tweet This:
“Don’t think of your product as a stand alone tool, but as part of a system of solutions.”
This could mean there are opportunities to partner with other companies who are selling to the same user personas you are, or who build products your target customers are already using, to make your products more valuable.
You might want to devote marketing or business development resources, for example, to finding vendors that also serve your user personas with complementary offerings — and aligning your products, marketing and even support with those companies to create more reach for both of your companies and more value for your shared customers.
When you can approach new customers not merely as a stand-alone tool, but rather as an integral part of the larger system, then you’re adding real value.
3. Develop and share APIs to make your software more useful in your customers’ actual workflows.
Another way to make your offerings more valuable to your customers is through an API that will help them integrate your products into the other commercial applications and other proprietary tools they use in their day-to-day workflows.
Considering that more businesses are outsourcing more of their workflows to SaaS tools, for example, it is becoming increasingly necessary that whatever product you are selling can easily and seamlessly integrate with the broadest possible suite of existing applications.
For example, many of the product teams who use our LIKE.TG roadmap software also use JIRA for their project management. We have built features to integrate a LIKE.TG roadmap directly with JIRA. This makes both LIKE.TG and JIRA more valuable for our customers who use them both in their product development processes.
hbspt.cta.load(3434168, '3f36d63f-fe4f-400d-ab83-a64b28767625', {"region":"na1"});
4. Automate more of your customers’ workflows with your products.
One of the best ways to add customer value to your products is to automate as much of the work they would have to perform as possible.
For example, some of the most powerful online marketing platforms — think Marketo and Hubspot — allow users to set up automated workflows. These could be lead-scoring systems or drip-marketing campaigns, which send out specific messages either at specific time intervals or triggered by specific actions taken by prospects or customers.
Building this type of automation into your products requires upfront work, but it allows you to solve real problems for your customers — saving them time, ensuring they don’t miss opportunities because they didn’t take an action manually, and helping them scale up their marketing efforts without worry.
5. Leverage the data you’re already compiling to create more value.
You are likely already collecting a wealth of data — terabytes and even petabytes of valuable, proprietary information on the customers you’re serving, your product’s performance, and your market in general. But most likely, that data is collecting dust.
Tweet This:
“Leverage the data you are already collecting to create more value for your customers.”
The good news is that, as with so many other technologies over the last few years, there has been a proliferation of data analytics and business intelligence tools coming online to help you make more sense of the vast amounts of big data you’re already compiling.
From development tools like New Relic, to business intelligence solutions like Tableau, you are in a better position now than ever to gain actionable intelligence from that data.
Pull that data down from the attic, look it over, and find new ways to turn it into value — both for your company and for your customers.
How? Here is one idea: Publish this data in the media to build name recognition and credibility.
Why not take the data at hand — anonymized, of course, to protect your customers — and create aggregate industry data reports that you can publish in media outlets that your user personas read?
Just as Monster.com uses the data it collects to release reports on the employment scene — whether jobs are growing or contracting, which industries are leading the way, etc. — you can aggregate your own platform’s data to generate informative and interesting data reports. This can establish your company as an authority and bring you new business.
Again, you’ll be creating real value for your customers and for the market — and all from simply leveraging the data you’re collecting and storing anyway.
Your focus should always be to add customer value.
With the widespread availability and affordability of powerful new tools for design and production, you can expect ever-more competitors to your products and ever-greater expectations from your customers. That’s the challenge.
But the good news is that none of these new technologies, tools or trends can undermine the fundamental and longstanding product management principle: You win by delivering value to your customers.
As long as you keep that as your priority, your products — and you — will be successful.
What other trends do you see today? Share them in the comments section below.
Help! I’ve Been Handed a Bad Product Strategy
On our blog we often discuss the challenges of being a product manager. One recurring theme is that although you are ultimately responsible for the success or failure of your products, you often do not have organizational authority over anyone.
It’s a conundrum: Your job is to develop a consensus and execute your product’s strategic plan without the authority to tell anyone what to do. You need to bring together development, marketing, sales, and even your executives to make that plan a reality. This is why we frequently make the case that successful product management is largely a function of leadership — not management (at least in the sense of ordering and supervising). It’s also why my team here at LIKE.TG has written several posts, like this one, about the need for product managers to learn how to think strategically, communicate persuasively, evangelize for their products, and develop other important soft skills.
Tweet This:
“Product management is largely a function of leadership — not management.”
But what happens when the product management challenge you face is that you have poor strategic direction to begin with?
In other words, what if you’re simply handed an ever-changing strategy and given responsibility for turning it into a successful product? Worse, what if you know that the product strategy is flawed or poorly conceived?
This happens all too often. And it happened to a product manager who attended a recent webinar on thought leadership that I presented for Pragmatic Marketing. I’ve reproduced a portion of the message here. Then I’ll summarize the advice I gave him, because I think it could prove useful for you, if you ever find yourself in a similar situation.
Hi Jim,
I have a question about working with a poor product strategy for a just launched product. Our ex-CXO developed the product strategy. Since his departure, the executive team doesn’t have the resources or energy to fix the problems he left, and I find it difficult to push out the releases and spend time on defining a new product strategy. Unsurprisingly, there has been weak adoption of the product by the market and few new users.
How do you deal with being handed a poor product strategy where the targeted customer segment isn’t clear, not enough time was spent learning about the potential users, and your executives don’t want to stop product development and do customer development in order to hone in on a specific segment, learn more about pain points and get super clear of value add?
How You Can Get Stuck with a Poor Product Strategy
As I told this attendee, this is an excellent question, because it summarizes so many of the challenges product managers and product owners face when their company’s ideas and assumptions don’t match reality.
Here are the challenges — every one of them a common problem, facing many companies, particularly startups — that I spotted in his question.
Software companies want to deliver new features.
This is understandable because it shows progress. It’s also an easy metric to focus on and can feel like an easy win. “Look! We’re releasing new features to the market!”
The more important question, though, is whether any of these new features will move the needle for the company in terms of user adoption, opening new markets, customer delight, and positive public reviews.
Executives work on assumptions — not always grounded in fact.
Another common product management challenge, clearly evident from this attendee’s message, is that often a startup’s executive team will be working off of their own assumptions about their market, their product, their competitors and their target customers.
This, too, is understandable. After all, the executives were responsible for getting the company off the ground, and as a result, they have probably developed a bias in favor of their own opinions.
At the attendee’s company, the previous product lead was clearly operating on his own assumptions. But as the product release revealed, he likely didn’t subject those assumptions to testing and verification before building them into his strategy.
hbspt.cta.load(3434168, '1f74539e-d4fc-4cb3-97c6-fd86de2bf62e', {});
Growing companies often feel the need to keep their developers busy.
The note in this message about the executive team not wanting to stop product development to focus on strategy highlights another common product management challenge. Often a management team or a company’s investor will equate a development team being busy — being “productive” — with the company making progress.
Again, that’s understandable from the standpoint that the company is paying for development resources, and the perception is that those resources will be sitting idle while the product team interviews customers, studies the market, and conducts other “fuzzy” tasks. It certainly isn’t as easy to measure as hammering out code.
Tweet This:
“Focusing on strategy is far more valuable than just keeping the dev team busy.”
But as smart product owners like this attendee understand, focusing on strategy is far more valuable than keeping a development team busy on the wrong things.
Product owners can become information silos.
One final problem that this attendee’s message highlighted is that often a company’s product owner — whether a product manager, VP, or founder — can become the organization’s perceived source of knowledge about the product, market, competitive landscape, and customer personas.
This is obviously a danger. If the rest of the product team has little to no input in developing the product strategy, the departure of one key individual can leave the company struggling to figure out all of the learnings and input that went into building that strategy.
The good news, as I told this attendee, is that a product owner can indeed improve upon a flawed or poorly conceived product strategy. Here are the suggestions I offered to him.
How to Fix a Poor Product Strategy
1. Assign a product owner (or team) to drive the strategy.
One key component to creating a viable product strategy is to assign a responsible person or team to the task. In other words, developing the product strategy needs to be a clearly defined role in the company.
If it becomes an informal, widely distributed task that everyone has a hand in crafting, your product strategy likely will be watered down.
Ideally, this will be a product manager, as I suggested to the attendee. But it could also be another product owner or even a small dedicated group of product team members.
For more on developing your product strategy, watch our webinar:
2. The product strategist must then bring evidence supporting these strategic initiatives.
If you want to improve a weak product strategy, you must first identify a few of the major strategic initiatives that will support your vision. These initiatives should emerge after working closely with customers (end-users, economic buyers at your customers’ organizations, etc.) to determine the problems they’re facing and how your product can solve those problems.
From there, you will be able to present real evidence to your stakeholders that these strategic initiatives support solutions that your customers need and are willing to pay for.
This means shifting the focus of your efforts from developing more product features to performing customer development — getting out there and talking with a cross-section of your customers and potential customers. What I suggested to my attendee, and what I’d also invite your team to do, would be to spend time on the road visiting with customers to identify the ideal segment, and to settle on a few of the most compelling problems to solve for that segment.
Tweet This:
“Handed a poor product strategy? Shift the focus back to customer development.”
A related part of your research here, of course, would be to validate that your target customers would be willing to buy your solution if it were to solve these major problems for their companies.
3. The product strategist should get company buy-in to shift focus temporarily from project management to crafting the new strategy.
Through customer development, you can prioritize your strategic initiatives. You can use a variety of methods to prioritize before developing your visual product roadmap. This roadmap will serve as your high-level blueprint for implementing your product strategy.
You and your team will need to step back temporarily from a focus on your backlog. Instead, you will need to focus on customer problems, describing how your product will help solve those problems and putting this into a strategic plan.
[Free book] Backlog Refinement: How to Prioritize What Matters ➜ hbspt.cta.load(3434168, 'ba6d6ffb-c21a-41c0-8f7e-7f79e553dae1', {});
As part of this process, you will need to communicate this plan to your executive team to earn their buy-in.
If you work at a smaller company you might also need to offload some of your day-to-day project management responsibilities so that you can focus on strategy. This might be more challenging, and you might receive pushback.
But if you’re going to avoid the problem my attendee faced — releasing an unsuccessful product because you were forced to work from a poor strategy — it will be worth convincing your stakeholders to give you this strategy time. It will pay big dividends on release day and beyond.
hbspt.cta.load(3434168, '3f36d63f-fe4f-400d-ab83-a64b28767625', {"region":"na1"});
Have other ideas for handling a flawed product strategy? Please share them with us in the comments section.
Product Lessons Learned: Interview With Shivan Bindal, Director of Product Management
This is the second in a series of interviews that we are conducting with product managers across various industries. We’re curious to hear about how they got into product management and about their experiences on the job. We hope this series will shed light on trends and challenges in the profession, and be helpful to new and experienced product managers alike.
The following conversation is with Shivan Bindal, Director of Product Management at Procore (a California-based SaaS company that builds software for the construction industry). Here’s Shivan’s story.
How did you get into product management?
Shivan Bindal (SB): I came into product management through consulting, which is one of the more traditional routes. There are three traditional ways to get into tech product management or software product management. One route is via the engineering department. Another route is through consulting, where you do parts of all different roles, and you can choose to narrow in on product management as a full-fledged career. The third route is through an MBA program, from which you can transition into an outbound product management role.
I came in through that second option. I had a background in software engineering and I managed engineers. Then, I moved into program management as a consultant for a boutique software consulting company. I decided that what I really loved about my job was product management, day in and day out. And product management is what I’m doing now and what I absolutely love.
What do you love about your job and what is the most challenging part?
SB: At the heart of it, being more of a technical product manager, I love solving problems. Identifying problems is a big part of the job, as is figuring out what customers’ true pain points are. You need to empathize with folks experiencing pain, and then actually solve their problems and remove their frustration.
As with any job, there are also significant challenges. I think one of the biggest challenges is the fact that, as a product manager, you own something that is intangible.
Tweet This:
“One of the most challenging aspects of being a product manager is owning something intangible.” #ProductLessons
Product managers are often described as “CEOs of the product.” Well, a CEO is responsible for a staff. But as a product manager, you own the product — you don’t own the engineering team behind the product. You don’t own the marketing team that’s responsible for taking the product to market and maintaining its success in the market. Nor do you own the sales team that’s responsible for selling the product.
Product managers are not general managers, so a big challenge can be fostering a collaborative environment. You need to get the job done, but you have to do so by exerting influence in indirect ways. You have to get stakeholders across the business — both internal and external — to not only buy into your vision, but to buy into the execution of that vision over time. I think that’s one of the hardest things any product manager has to reckon with.
How do you manage conflicting priorities within your organization?
SB: As I always tell people and reiterate to myself, there’s the science of product management and then there’s the art of product management. Things like dealing with individuals, fostering collaboration, and ensuring that everyone is marching to the same drumbeat really entail more art than science.
I think you have to understand motivations when individual priorities conflict across the organization. You have to understand who’s driving the priority, what’s driving them and why they’re even at the table — why do you need them and why do they need you? Having a very clear answer to those questions will help you arrive at as many win-win scenarios as possible.
All relationships have to be mutually beneficial — what’s a priority for you needs to also be a priority for your stakeholders. If that’s not the case, then you need to reevaluate.
It’s often the case that you’re just talking to the wrong person. If you’re talking to a go-to-market specialist, they may have a harder time understanding the strategic value of what you’re working on compared to someone who has a broader view of where the company and product line is going.
But, competing priorities are always something you have to battle. As a product manager, you have to walk the line and ask yourself, “Am I right or is the other person right?” And then you have to suck it up and just do what needs to be done in order to move forward.
Another aspect of managing conflicting priorities is identifying what it is you’re really trying to achieve. In traditional scrum, when you’re prioritizing backlogs, you often have to deal with the question of whether to build new features or fix technical debt. You may also be weighing capabilities that were previously put to the side because of MVP-type release strategies.
At what point do you go back and fix things or build what you never did? Or is it better to just focus on building the next shiny thing?
I use a very simple model that some old colleagues and I came up with called ARC, or Acquisition, Retention, Consumption. The goal is to ask yourself, “What am I trying to accomplish?”
Are you trying to encourage more adoption of your product? Are you trying to get people who are using your product to use it more? Are you trying to get people who are using your product to stay with your product? These questions help me not only in identifying which priorities make sense and also in communicating these prioritization decisions to stakeholders.
What tools or software can you not live without?
Evernote is a great tool for taking notes and staying organized, which is really important given product managers talk to lots different of people — both internally and externally — about all kinds of things. Trying to keep your head on straight can be really hard.
I read Ronnie’s interview, and I agree with him that Post-it notes are also a great tool. I used to use digital Post-it notes for reminders, but I’ve since moved on to using a Trello board to organize my tasks. There’s a sense of accomplishment with the Kanban-style of task management. You can track tasks through the workflow to completion, which is really helpful.
On the product management side, we use LIKE.TG for our roadmaps and to ensure we’re all in alignment on whatever we’re doing over the next three, six, and nine months.
And finally, it’s very old school and traditional, but I cannot live without the suite of Microsoft Office products. I need to be able to write a document, write a spreadsheet, or write a presentation and leverage it. These days, though, I tend to use the Google Apps more than I use Microsoft products because of their collaborative nature.
Cloud-based products are very helpful in not only communicating ideas and sharing them broadly within the organization but also in helping us on the execution side of things with our engineering squad. When we’re prioritizing our backlogs and creating our sprints, we can collaborate in real-time in our daily stand-up meetings.
Download the free Backlog Refinement: How to Prioritize What Matters Book➜ hbspt.cta.load(3434168, 'ba6d6ffb-c21a-41c0-8f7e-7f79e553dae1', {});
Describe your organization’s roadmap planning process. How far out do you plan?
SB: We employ the Spotify squad model here at Procore, which is oriented around autonomous, cross-functional units. Our engineers, QA, user experience, and product management folks are all co-located and focused on a specific problem space, whether it’s a small or broad one. The size of the problem doesn’t really matter; it’s about the impact and the solutions.
Tweet This:
“The size of the problem you’re solving doesn’t matter. It’s about the impact.” #ProductLessons
The squads operate very autonomously. They discover problems they need to solve, then they ideate, brainstorm, and design. They operate in a safe space, where their ideas can be quickly validated with direct outreach to clients. Then they move on to prototyping and developing the solution, and ultimately integrating it into the product.
So that’s how we build products here at Procore, and our product management team members fit that model into their processes and practices. We’re very agile. Our roadmap is strategic in nature, so we know the problem spaces we want to solve over the next three, six, nine, and 12 months. We plan roughly a year into the future, so at any point you can get a 12-month overview of what we are doing.
Because we are agile, we can’t always predict precisely when a feature will be ready or when we will start working on something. I would say we have higher confidence in the roadmap items that are three months out compared to the ones that are 9 or more months out.
How do you incorporate customer feedback into your roadmap?
SB: Customer feedback is a fundamental part of what we do. We are very market-driven and user-centric. The initiatives on our roadmap should provide value either to our prospective client base or to our existing client base. In general, every item on our roadmap is something we’ve heard about from our clients.
Depending on how far in the future an item is on our roadmap, we may or may not have confidence that it’s something we’re going to pursue. When we look at a roadmap item that’s six months out, we know that there’s some customer pain behind it, but we can’t quantify that pain. We can’t identify what the real problem is because we haven’t done a lot of discovery yet.
With items that are three months out, on the other hand, the product manager has definitely been doing research — perhaps with other stakeholders in the company, either from sales or marketing or the customer success team. The goal of this research is to really understand customers’ pain points so that we can articulate them well to others in the company.
At Procore, we align ourselves around solutions and we make sure to validate those before we begin any engineering work. We do not want to invest time into anything that does not realize value for our business.
As any growing software will tell you, sometimes the problems we’re solving are oriented around success and scale. For example, we may ask: Can we continue to onboard clients at our current pace in a sustainable manner? If the answer is no, we may enhance the onboarding process to alleviate some of the manual work.
In that example, we are solving problems for internal stakeholders — customer success and support individuals, rather than external customers. Internal stakeholders are our customers in this scenario. It’s not always external customers that we do our validation work with. Feedback is an important part of everything that happens within product management, and it’s certainly part of the roadmapping process.
What are some big product management mistakes that you’ve witnessed?
SB: All the mistakes I’ve made have helped me to become a better product manager. In the past, I’ve made the mistake of simply accepting what other stakeholders say. As a product manager, you can’t do that. You have to get outside your four walls and go back to the fundamentals of problem discovery and validation. You have to validate that what your stakeholders told you is in fact a pervasive problem and that solving it is worthwhile from an investment standpoint.
That’s not to say you need to get lost in ROI calculations or total cost of ownership calculations all the time. However, you do need to ask some basic questions: Does the problem exist? Is it pervasive? Is it part of the core competence of your company or your product, such that you should invest in solving it?
If you can answer those questions affirmatively — and if you can be confident that your sample size for the validation was large enough — then I think you are in a good place to embark upon solving the problem.
What would you say is the most important skill for a product manager to have?
SB: The scope of product management is all over the board. Some people differentiate between product owners and product managers, and between inbound product managers and outbound product managers. Other people confuse program management for product management, and still, others consider product marketing and product management to be interchangeable.
So there’s a lot of confusion around the term itself. If I had to choose the most important skill for product managers, I would have to clarify whether we’re talking about internally-oriented product managers in technical roles or more strategy-oriented product managers.
Tweet This:
“The most important trait I look for when hiring new product managers is insatiable curiosity.” #ProductLessons
The crucial question is: Can you understand the product? And can you understand what the market needs are? There are a lot of must-have skills for product managers, which is what makes our role so challenging and so dynamic. You get to explore so many different skill sets throughout the course of your career — it’s truly rewarding.
The most important thing I look for when I’m hiring is: Does this person demonstrate an insatiable amount of curiosity? A curious product manager is one who will never be satisfied with just one answer.
Another important skill is the ability to recognize patterns. Can the person identify patterns intuitively as well as statistically? Can they look at a set of data or parameters, or a set of answers to questions they’ve asked, and discern a compelling conclusion? And it’s important that their conclusion is not grounded in fallacy, and that it is not supported by confirmation bias or any other sort of bias that would prevent it from being objective.
How do you stay up-to-date on product management?
SB: The most beneficial information I’ve learned has come from reading. I think reading relevant blogs and books is really important, as is routinely putting your own thoughts out there for feedback.
I think Scrum and agile principles should be applied at the individual level. One of the big things I always advise product managers to do is to hold retrospectives for themselves. Find 15 minutes per day, perhaps on your drive home, to really think critically about the day’s events.
Did that client call go well? What could you have done to make it better? Could you have asked the questions in a different way? If there was a source of frustration, what can you do next time to alleviate it?
Tweet This:
“Apply agile principles at the individual level and hold retrospectives for yourself.” #ProductLessons
And it’s also important to apply the information that you collect along the way. Reading has really helped me expand my skill set, and it has expanded the set of things I consider when I’m thinking about how I can improve myself during those retrospectives.
Another really great tactic, which I can’t speak to much personally, is to find a compelling mentor who is successful in the field you want to be in. Be inquisitive and leverage the curiosity that you inherently have — really challenge other people to help you. All product managers should be constantly oriented around improving themselves.
Have a product management story to share? Contact us at [email protected].
Product Lessons Learned: Interview With Ronnie Regev, Sr. Product Manager (Part 1)
This is the first in a series of interviews that we’ll be conducting with product managers across various industries. We’re curious to hear about how they got into product management and about their experiences on the job. We hope this series will shed light on trends and challenges in the profession, and be helpful to new and experienced product managers alike.
Our first conversation is with Ronnie Regev, an experienced product manager at AppFolio (a California-based SaaS company that builds software for property managers). Here’s Ronnie’s story.
How did you get into product management?
Ronnie Regev (RR): Like many product managers, my route to the role was long and indirect. There aren’t a whole lot of people who finish school and end up in product management right away. Most people come into it from something else — and in my case, I spent about eight years working in infrastructure and operations in the video game industry.
It was a very interesting job and it was very technical. But I grew increasingly frustrated with being on the receiving end of business decisions that were made really far away from my team. Inevitably, my team would have to solve problems that we weren’t involved in identifying or qualifying. Also, because we were in a back-end type of role, it was difficult to see how the work we were doing was directly contributing to the success of the company.
Over the course of several years, I started to take on a bit of that frustrated mindset. It never affected my work, and I was still really happy in my job, but at a certain point, I decided to leave the company. I had been working there for a long time and I wanted to do something a little bit different.
As I started interviewing for other IT infrastructure operations leadership roles, I realized that I actually wanted to try something else. Through a friend, I was introduced to the director of product management at RightScale, who told me that I might find product management interesting.
I had a pretty open mind. I was starting to figure out what I didn’t want to do, but I still needed to figure out what I wanted to do. I thought, “Well, product management, I don’t really know very much about this. It’s just a conversation. Let’s see how it goes.”
What seemed really appealing to me about RightScale was that I’d be able to use my subject matter knowledge — my understanding of systems engineering and infrastructure and scalable web systems in a new, more challenging and satisfying way. I’d be speaking to people who used systems like the ones I was used to using, understanding their challenges and then working with engineers and designers to actually build software that solved their problems.
I didn’t even realize that was a job — something that somebody would be willing to pay me to do. When I put everything together, I thought, “Wow this seems like such an appealing idea.”
I’d get to use my historical knowledge and my interest in speaking to people about what’s difficult for them to inform how software gets developed. And I’d get to to be hands on with a technical team. Product management is not purely a marketing-facing type of role — there’s still this technical aspect of it which was appealing to me with my career background.
That was my path into product management. I happened to meet the right person at the right time, and it clicked for me. I met the director of product management at RightScale, who was able to identify that I had whatever intangible qualities a product manager should have and gave me a chance in the role. After two years at RightScale I moved on to AppFolio for a new opportunity and, over four years later, I’m still happy a Product Manager.
What do you love about your job and what’s challenging?
RR: What I love about the job and what’s challenging about it are sometimes the same thing.
I love that point in time when we’re about to release a new feature or a new product to our customers. There’s this nervous excitement that my team has. It’s a really special time because it’s the result of a lot of hard work, and maybe also some frustration and arguments.
Another reason for excitement around a feature release is the anticipation of user feedback and usage data. We may be confident in the choices made but qualitative and quantitative feedback is the proof! Once we get that proof it reinforces the positive impact on our customers’ business and AppFolio’s as well; exactly the kind of career choice validation I sought!
A lot goes into that moment when we’re about to release something — a lot of individual opinions and insights from our customers. And it doesn’t necessarily have to be a big new feature or a big new product. We could be releasing something really small — in which case, the excitement is based on challenging our own assumptions and assertions.
Tweet This:
“Always question your assumptions.” #ProductLessons
Another thing I love is collaborating with the teams that I’ve been fortunate enough to work with — QA engineers, designers, and software developers who are really interested in solving problems and invested in understanding the context we’re working in. Being part of these teams has been a fantastic privilege and it makes work so much fun.
As for the things that are hard, I’d say combating my own biases is challenging. Like anyone else, I have my assumptions about what’s most valuable for our business, what’s most valuable for our customers, what the best path is in solving a particular problem. The hardest thing is to extract myself from those assumptions and overtly challenge them. But that also kind of falls in line with the things that I love about my job, because I consistently learn about myself, product development, our customers, etc…
Another thing that’s really difficult is always maintaining a focus on customer value. It’s easy to start thinking that we should do something because we’ll make more money — or because maybe we think we can grow adoption or satisfy an internal stakeholder. But at the end of the day, we should be focusing on delivering value to customers, and all those other things will follow.
How do you manage conflicting priorities within the organization?
RR: All of the conversations that I have with different stakeholders — with executives, sales, marketing, customer success, and engineering — are focused on a particular problem that we want to solve or an opportunity that we’ve identified to deliver value to our customers.
We frame discussions in the context of how does this align with our goals as a business? And the product management group has the benefit of very strong insight into our company goals.
Tweet This:
“Frame discussions in the context of business goals.” #ProductLessons
To use generic terms, goals for a company could be to increase the adoption of certain features, to increase revenue, or to become more profitable, etc. Whatever those goals are, they’re very clearly communicated to the product team and expressed throughout the organization.
Let’s use a hypothetical goal — to increase adoption of a particular product line, for example. That message will have been communicated to department leaders by the VP of Product and by the Directors of Product.
We get direction from the top down — from our board of directors, to the C suite of the company, to the VP level, and then down to the product line owners. There’s a lot of vertical alignment on what we’re trying to accomplish as a business. So when we’re framing a conversation around trying to increase the adoption of “x” product line, there’s very little debate around why are we trying to increase the adoption of “x” product line in the first place.
Company alignment is being worked on all the time — both vertically, up and down the corporate ladder, and horizontally, across all parts of the organization; product development, engineering, customer success, sales, marketing and operations. So for us, managing conflicting priorities is well solved by ensuring that there’s consistent alignment on goals.
What are some of the tools you use regularly as a product manager?
RR: I have a couple different classifications of tools. I have tools that I use personally for my job, and tools that I use in a group setting.
Evernote is a great example of a tool that I can’t live without. I have years and years and years of notes in Evernote. I’m also a very heavy user of Google Apps — Google Drive, Gmail, and Google Calendar. I use Google Docs, Google Sheets, and Google Presentations. Specifically, I find the collaboration aspect of Google Docs indispensable.
Also, I almost always have a pen and some Post-it notes in my pocket. My wife makes fun of me because I will usually slip a little pad of Post-its and a pen into my shirt pocket before I leave in the morning. She’ll call me a dork or a nerd and ask me if she should buy me a pocket protector. I’ve actually had ink open up in my shirt pocket before.
For team-oriented work, I’m not very dogmatic about tools. My view is what’s the best tool for the job? And we have myriad tools that are employed here at AppFolio. For example, we have some teams that do all of their planning work on a whiteboard. Someone will draw up a scrum board on a whiteboard so we can track stories to groom, work in progress, and so on.
We also have teams that work with Trello and other teams that work with Pivotal Tracker for managing backlogs and tracking work in-progress. One other tool that I find particularly valuable is called Kanban Tool — we use it a lot for user story mapping sessions. It’s a good way to capture and memorialize information.
Beyond that, it’s important to have consistency in tools that are used to communicate across the organization. For example, we use Google Sites to capture release literature and send it around internally — and it’s always the same form and the same destination. People in the company know where to go to find release notes.
Additionally, all of our product managers use LIKE.TG to track their two-to-eight-week roadmaps, and those roadmaps are always in the same format. Anybody in the company who receives a roadmap knows what it’s going to look like — they know it’s not going to behave any differently.
My personal go-to tools are Google Apps, Evernote and Post-its. When it comes to the tools that my teams use, I’m happy with whatever tool is appropriate for the job. And if it’s a tool that’s being used to communicate broadly, then I think consistency is more important than the type of tool chosen.
How do you plan your product roadmap at AppFolio?
RR: At AppFolio, product managers maintain roughly a two month outlook on what their teams are doing. I frankly don’t know the origin of that time horizon — maybe we originally had a two month release cadence at some point.
Anyways, each product manager owns the visibility into the next two months of work for their respective teams. Now, two months out, things are still kind of vague. The closer we get, the greater our confidence in estimates and in the fidelity of the problems that are going to be solved.
For historical reasons, our sprints are in two-week cycles — even though we now release code on a weekly basis. But since everybody in our company is used to “sprint” meaning two weeks, we’ve kept that definition. Product managers therefore work with blocks of two weeks at time on their roadmaps.
Typically, the product managers will meet with their teams once or twice a week for very informal sprint planning. Then they’ll update the two-week horizon, the four-week horizon, the six-week time horizon, and the eight-week time horizon. Predictability and certainty of roadmap items decreases further out on the roadmap.
Our roadmaps are communicated to the whole organization every two weeks, in a traditional roadmap form — with swimlanes, blocks, various colors, and so on.
Now, for the longer-term view, we don’t really have roadmaps. We have six themes that are derived from our business objectives. These are things like expanding our market, increasing feature adoption, enhancing our user experience, retaining our promoters, etc. We revise our themes every six months because things change, or because we’ve made a lot of progress toward one theme and there’s no point in continuing — we shift to another one.
Product Managers and User Experience Designers are paired to curate a theme backlog. They’re responsible for working cross-functionally to understand the various needs across the organization. They talk to customers on a regular basis, quantitative analysis, perform market research to identify and qualify opportunities. Then, using that data, they curate a backlog of problem statements that are then prioritized for teams to pick up.
Tweet This:
“Curate the backlog based on user input and quantitative analysis.” #ProductLessons
Teams have three top priorities across all the various themes, and product managers influence the teams towards certain themes. So, if we feel like we need to put a lot of emphasis on increasing adoption of a particular feature, then that message will be conveyed.
Download the free Backlog Refinement: How to Prioritize What Matters Book➜ hbspt.cta.load(3434168, 'ba6d6ffb-c21a-41c0-8f7e-7f79e553dae1', {});
The product manager will say, “Hey, pick one of these three opportunities. Don’t pick something from the expand our market theme. We’ve done that. We have a lot of work in flight over there, or we’ve put a lot of groundwork in place already for expanding into adjacent markets.”
It’s really up to the Product Manager – User Experience Designer duo to curate and present the opportunities to the teams, and then the teams pick what they want to work on. What they pick then ends up on that two-month roadmap.
Have a product management story to share? Contact us at [email protected].
Product Lessons Learned: Interview With Ronnie Regev, Sr. Product Manager (Part 2)
This is the second part of our conversation with Ronnie Regev, Sr. Product Manager at AppFolio (check out the first part of our interview with Ronnie). Ronnie is the first of several product managers we’ll be interviewing about their careers. Read on for Ronnie’s advice on listening to customers, asking the right questions, challenging your assumptions, and more.
How do you incorporate customer feedback into your roadmap?
Ronnie Regev (RR): Customer feedback has a direct role to play in the two month roadmap or and long term product themes (see previous post). When we release an MVP (minimum viable product) — or when we release something that’s likely to test our assumptions or challenge our next big hypothesis — we’re actively looking for customer feedback. At that stage, feedback has the power to directly influence our roadmap planning.
Sometimes we’ll intentionally release something that is missing a particular function we assume might be needed — for example, the ability to notify users when a certain task is completed. We can just assume that customers need notifications, or we can wait and explicitly seek to hear whether or not notifications are really necessary. And if they are necessary, what form should they take? Through which medium? Is there a better way of conveying the information the user needs?
Customers may start telling us that the new feature is great, but they have no idea when their staff has completed a workflow. They may say, “If I don’t know when my staff completes their workflow, how do I know when I need to go do these other things that I’m responsible for?”
If we hear feedback like that consistently — to the point where it affects someone’s ability to adopt the new feature or their willingness to use it — it may indicate a need for us to build notifications after all. Then we’ll say, “Great, this is the next thing that we’re going to work on, and it may even leapfrog other priorities on our roadmap.”
Customer feedback is also a big factor in both determining, and curating the theme backlogs. There are many channels that our customers can leverage to convey their needs. We use UserVoice to collect feedback, set feature delivery expectations, and encourage our customers to vote on the ideas. AppFolio has an excellent customer loyalty team that works with customers on driving feature adoption and getting ahead of churn risks. This group is an excellent source of input into the pervasive challenges experienced by our customers. We pay particular attention to things that are challenging during the implementation process. Sometimes customers churn because the implementation of a particular feature is really difficult and painful, and if that’s the case, heavier weight is given to things that will fix the problem.
Lastly, the product and UX teams gather feedback from the field on a regular basis. We all travel to AppFolio hosted meet-ups quarterly in order to maximize customer face time and conduct several in-depth office visits per trip.
What are some of the biggest product management mistakes you’ve witnessed?
RR: I’ve witnessed many product management mistakes, many of them my own. One of the biggest mistakes I’ve made is forgetting to challenge my assumptions. How do we really know that our customers are frustrated with the way a particular feature works? How do we know that we must absolutely build this additional functionality?
Questioning my assumptions, and really doing it adamantly, is a consistent challenge. Forgetting to question things is a mistake that I see new product managers make all the time. Maybe they don’t want to challenge a very senior engineer, or the CTO who is passionate about a particular feature to build.
As a product manager, it’s your responsibility to validate those statements. If you don’t, the ramifications are potentially wasted time, misguided efforts or pursuing pet projects..
I’ve seen this with associate product managers who are new to the role. Sometimes they won’t question the assertions that a more senior team member makes.
Another common mistake I’ve seen new product managers make is not putting enough emphasis on learning the product, understanding the market, and learning about customers before diving right in.
Tweet This:
“You’ll solve problems the wrong way if you don’t take time to fully understand the context.” #ProductLessons
You will start solving problems the wrong way if you don’t take the time to fully understand the context — or, in the case of B2B software, the customer workflow and motivation. How and why are they doing this today? That’s what a product manager needs to understand to be effective. It’s a mistake to try to jump in prematurely, without having the background knowledge necessary to ask the right questions.
Finally, I have one last really specific mistake that has to do with third party integrations: Don’t build to the spec of an API that doesn’t exist yet. You’re basically building something on the hopes that it’s going to work a particular way, but you don’t actually have any proof.
That’s a mistake I’ve made, and the lesson I learned is that when you’re working with third parties, wait until the integration point is real and you can actually see programmatic responses before you start building software. Otherwise you could end up sinking a lot of time into something that takes you down the wrong path.
What is the most important skill for a product manager?
RR: I think the most important skill that a product manager can develop is knowing how to ask questions the right way. Again, we all have our own biases, our own opinions, and our own assumptions. But when you’re interviewing people to understand what they’re trying to accomplish, and what’s difficult for them, you need to discard those biases. That can be accomplished by learning to ask non-leading questions.
I typically hear new product managers ask customers, “Would you like this? If we develop a feature that does X, Y and Z, would you like it?”
And the customer will say, “Sure, I’d love it. That sounds great.”
I coach our new product managers to instead ask, “How would you use this particular feature?”
And then, I encourage them to sit there quietly until the customer actually answers the question. That’s actually another tip for asking questions the right way: Ask an explicit question, and let the person answer the question that you’ve asked.
Don’t add on additional qualifiers or tack on other questions. Ask the question in an open-ended format and wait. You want to understand how the customer will use something and why it’s important to them. You need to give them enough time to actually think through the answers to those questions.
I learned how to properly ask questions by listening to recordings of other product managers conducting interviews, reviewing my own interviews and seeking advice from our User Experience researchers.
The ability to ask well-structured questions helps product managers develop empathy, which is another really important skill to have. Empathizing with customers — understanding what they’re struggling with and what’s valuable to them — informs your prioritization and development decisions.
How do you stay up-to-date on product management?
RR: I definitely prioritize staying up-to-date on product management. It’s very important for my career development to continue learning the theoretical stuff, so I read about the experiences of other people in my field. I prioritize reading blog posts and listening to podcasts.
I try to listen to product-related podcasts that are 30 to 45 minutes long, because that’s about my tolerance for jogging. I’m subscribed to a number of different mailing lists, which provide a curated list of articles that I value. I also follow key people on Twitter and read the things that they’re recommending.
At AppFolio, I often have the benefit of being sent to different product development conferences. I usually go as a litmus test for whether or not we should send additional people — engineers, UX designers, researchers, etc.
We have a strong philosophy of experimentation at AppFolio. I learn a lot from my colleagues who apply different approaches. I remember meeting a friend about six months after I started here and he said, “You seem like you’re doing great. How did that happen? How have you learned what you’ve learned?”
I said that I’ve learned nearly everything through my colleagues. The saying that “a rising tide lifts all boats” is the way I see the product management team at AppFolio — there are a lot of informed, smart people and we learn from each other. It’s not just product managers that I’m learning from either, learning from other peers is a critical part of how I keep up-to-date. The two colleagues who push me most, in a constructive way, are a lead QA engineer and Director of Engineering.
As for the piece of advice I’d give to new product managers, it’s hard for me to single out just one thing. But if I had to choose, I’d say learning about your market, your customers, and your product is important. Learn those things, because it’s crucial to be a subject matter expert. You’re the voice of the business and the voice of the customer.
Tweet This:
“You can’t do your job effectively if you don’t prioritize learning about your product and market.” #ProductLessons
You can’t really do your job effectively if you don’t prioritize learning. A newly hired product manager at AppFolio recently asked “I’m getting pulled in a lot of directions — what should I do? I’m shadowing a product manager. I’m getting involved in team activities. There are all these meetings.”
My advice was, “Your job right now is to understand our market, understand our customers, and learn all about our product. Build that base, and you can do the other things afterwards. But build that base first.”
What is the craziest feature suggestion you’ve received?
RR: A crazy suggestion that I love getting from our customers is, “Why don’t you just do exactly what your competitor is doing? Just do what they’re doing, and you’ll get it!”
It’s an interesting recommendation, and I usually reply by asking, “How long ago did you switch from our competitor to us? And why did you switch?”
There will be some good reason: “You guys do this and this really well.”
And I’ll say, “Okay, well, why do you think we should copy them?”
Finally, the customer will say, “Well, on second thought, maybe you shouldn’t copy them. There’s a reason why we switched to you guys. Keep on doing what you’re doing.”
But that’s the suggestion I love the most. If we just follow what everybody else does, we’re not going to deliver differentiated value to our market. We’ll just be a copycat product, and that’s not sustainable.
Have a product management story to share? Contact us at [email protected].
Aligning Sales and Product Teams on Your Roadmap
One of the biggest challenges product managers face is working with diverse stakeholders and managing their conflicting priorities. You’re pulled in a hundred different directions, and often it’s the sales team applying pressure on your roadmap priorities.
At times it’s tempting to build what the latest big sales prospect asked for. And sometimes, to close the deal, it’s tempting to make promises on release dates or to mention features that are still a few months out on the roadmap.
I’ll elaborate on some of the points I made during our recent webinar, and explain how product managers can better work with sales teams to ensure they don’t over-promise and under-deliver.
What successful methods have you found to manage the sales team selling roadmap features before readiness?
The sales team understandably is looking for ways to close the deal. That’s how they’re compensated, and I think it’s important for product managers to recognize that.
You can set expectations with the sales department that plans will change and you can talk all you want about being agile. You can tell them that you’re not sure when the exact delivery dates for certain features will be. But the reality is that when you send the sales team a roadmap, many will consider it to be a commitment.
The last thing you want is for sales to be attaching a copy of that roadmap to a customer contract. One option to consider: creating a separate sales-oriented roadmap — one that doesn’t have dates and that is less granular. A sales-oriented roadmap could also limit the timeframe, showing just what you’ll be delivering in the short term — maybe three months out.
It’s important to involve sales leadership in the roadmap planning process. Not only does it get their important input, but it helps establish buy-in. You also have the opportunity to guide them on why certain features are important from a strategic perspective.
hbspt.cta.load(3434168, '3f36d63f-fe4f-400d-ab83-a64b28767625', {"region":"na1"});
How do you keep sales and product teams on the same page?
It’s important for product managers to make sure that the sales team is targeting the same market that the product team has identified for the product. Product managers usually work with personas, and I think that’s a really important concept, but sales teams may not necessarily have a similar sales persona.
For example, let’s say you’re a B2B company and you’re targeting companies with 1,000 to 2,000 employees. Well, your sales team better be doing the same. You’re building a product that solves a problem for that market, but if your sales team is then approaching startups, there’s going to be a problem. A product/market mismatch. The sales team will inevitably be disappointed, and of course, the customer will inevitably be disappointed.
You need to make sure that there’s alignment between your target market and the market that your sales department is actually selling to. Everybody should be pulling for the same team.
Tweet This:
“Make sure your target market matches the market your sales team is actually selling to.”
Also, I think it’s important to nicely remind your stakeholders that sales and revenue aren’t the only success metrics. The success of a product is based on a whole lot of other things. For example, customer satisfaction after a sale is critical. If your sales team is selling actively but you have a lot of customers churning, that’s not good. So it’s important to recognize that there are other metrics out there besides sales that are worth paying attention to.
Get Buy-In and Budget Approval on Your Product Stack➜ hbspt.cta.load(3434168, 'c4f7dcc8-378e-4b20-9c16-637fcb9589a5', {"region":"na1"});
How do you avoid getting distracted by high-paying clients?
When a high-profile client comes in and asks for a feature, it means something else is not going to get built. If everything is equal, if one feature is added to the roadmap, another one moves out. And it’s easy to get distracted from your core roadmap when a large prospect says, “If you build this feature, we’ll buy.”
Check them against your strategic objectives — this is where having those clear objectives and goals mapped out with your team becomes really critical. You need to make sure your team is aligned on strategic goals because if you’re making these decisions by yourself, you’re going to have an even harder time weighing the risks and benefits.
Whatever this big deal is that’s being dangled in front of you, the feature they’re requesting needs to be tied back to your product vision. If you’re doing a good job of that, then it should be fairly clear what the right answer is. Sometimes it’s tough but you just have to say no or not yet.
Have other suggestions on how to better align sales and product teams? Share them in the comments below.
Why User Onboarding Never Ends (And Why Product Managers Should Care)
The traditional approach to user onboarding
When software companies reference user onboarding, they are typically referring to the user’s initial experience in the application. The concept took shape around mobile apps, but as more and more business software moved to a SaaS, “self-service” model, vendors began to introduce distinct onboarding experiences for a user’s first visit. These experiences are designed to introduce the user to key features and functions of the application and walk them through some sort of setup or training flow.
These simple onboarding experiences can be helpful, but they typically do not end up being a priority for the product management team for a couple of reasons. First, the onboarding experience is often treated separately from the overall user experience. It’s considered a ‘one-off’ and any updates or refinements often end up de-prioritized on the roadmap. Second, onboarding initiatives are often championed by sales or customer success teams within the organization. Although product management will lead the implementation, they may not feel the same level of ownership or accountability as they do for other features in the product.
As a result, user onboarding doesn’t necessarily get the attention it deserves. The same trends that are driving self-service delivery of business applications are dramatically reducing switching costs for customers. If they don’t realize value quickly or feel that the application is delivering against their expectations, they will churn. Regardless of the breadth of functionality that is available, if users can’t learn it quickly, the product won’t be successful.
A better definition of onboarding
Part of the challenge stems from the fact that onboarding has a very narrow definition for most companies. Rather than thinking about onboarding as the initial user experience in the application, companies should be thinking about it as the process by which users become proficient in the application. This definition is helpful for a couple of reasons. First, it opens the aperture beyond just the in-application experience to understand that onboarding also includes any hands-on help, account setup, and training. Secondly, and most importantly it helps to clarify that onboarding doesn’t just refer to a user’s initial experience in the application.
Tweet This:
“A better definition of user onboarding: The process by which users become proficient in the app.”
It’s definitely true that users will churn if they don’t realize value quickly, but it’s just as true that users will churn if they don’t receive ongoing value. The SaaS business model is built on the idea of recurring revenue. Customers must renew and expand their usage for a product to succeed in the long run. This means that product managers must consider how they deliver additional capabilities at a velocity that meets customer expectations for both actual and perceived value.
Implications for the user onboarding experience
Along with all this ongoing capability delivery, products must also be able to provide ongoing onboarding delivery. Added functionality is of limited value if users are unable to discover, and learn how to use it. This means that product managers must think through how to add more flexibility to the onboarding experience. Taking over the UX for an introduction and initial walk-through is fine (if not ideal) for the user’s first experience, but it definitely isn’t a workable approach for every new capability that is introduced. Also, if onboarding truly doesn’t end, product teams need to address how to handle the volume of onboarding content. Adding too much guidance or training to the user experience can add clutter and ultimately degrade the customer experience.
An effective approach is one that customizes both the onboarding content and the delivery to the user’s context and learning style. User context includes behavioral and demographic information such as:
Time spent in the application
Features used
Previous onboarding/guidance viewed
Functional job role
Application role (i.e. admin vs regular user)
This information can be used to target onboarding content to the users that it’s most relevant for. As a simple example, you probably wouldn’t want to offer help about a particular feature to a user that has already used that feature several times. The offer would merely be intrusive. This same principle applies to content a user may not have access to. If their plan level or role in the application prevents them from accessing a feature, any help for that feature should be hidden from them as well. By limiting content like this, product managers can ensure that their onboarding experience is as relevant as possible, and doesn’t unnecessarily clutter the user experience.
Supporting different learning styles is often addressed by offering content in a couple of different formats. For example, onboarding content can be delivered as:
In-application walkthroughs
Instructional videos
Written documentation
Training classes
All of the methods might be preferred by different segments of users. Once a base set of onboarding content is developed, it’s not a significant burden to surface it in a couple of different formats. Product teams can test several different formats or combinations of formats to see which ones are consumed the most by users.
Considerations for the product roadmap
How should the need for continuous/constant onboarding influence the product roadmap? Ideally, onboarding requirements and measurements should be included with every item on the roadmap. That way, when the product team is prioritizing and scoping features, they can consider the time and effort involved in training users about the feature. It also ensures that a feature is not considered complete if the content and the approach for “onboarding” users into that feature has not been developed as well.
Tweet This:
“Onboarding requirements and measurements should be included with every item on the roadmap.”
Metrics around onboarding should live with the overall feature metrics. Often, usage goals will overlap with onboarding outcomes – i.e. a successful feature and successful onboarding will result in a high-level of feature usages and possible increases in user satisfaction. The key is that the onboarding experience should be evaluated alongside the feature itself. This allows the product team to constantly measure not only the pick-up of the feature but the engagement with the relevant onboarding content as a part of their retrospective process.
Embracing onboarding as an ongoing process
It’s easy to treat user onboarding as a one-off experience that doesn’t need continued investment, design, and attention; but in today’s world of SaaS and recurring revenue business models, product managers do so at their own peril. The reality is that in order for applications to be successful, their users must realize value quickly and continuously. The only way to support this is through ongoing user onboarding. Product teams that embrace onboarding requirements and measurement as part of their roadmaps, and who work to customize onboarding content to user context and learning styles, will come out ahead.
About the Guest Author
Michael Peach is the Head of Product Marketing for Pendo, where he leads messaging, positioning, and launch activities for Pendo’s product success platform. Prior to joining Pendo, Michael was the marketing program director at IBM where he led marketing and demand generation initiatives for their mobile, application integration and business process management portfolios. He has also held product management and business development roles for several small and early-stage technology companies.
