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

 

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

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

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

We should start with a couple basics…

Definition of Success of a Product Roadmap: 

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

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

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

Start with the Customer

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

Clearly Define Problems You’re Solving – Your Roadmap Themes

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

Facilitate Innovation/Design Thinking

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

Build Shared Vision…and Commitment

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

Understand ALL Your Critical Path Dependencies

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

Ongoing Management

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

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

Happy Roadmapping Season!!

 

 

Defining the PM job

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

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

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

So, we came up with a new graphic:

 

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

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

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

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

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

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

Persona Pitfalls

 

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

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

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

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

Here are some tips to apply tomorrow:

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

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

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

 

 

 

The Rebellion is here.

We thought we’d start with our story. We are two product leaders who are tired of seeing product managers struggle.Tired of watching YOU struggle to do the right thing. Tired of product managers being mistaken for project managers. Tired of you not having the support you deserve. Yes, we’re speaking to you – the product manager who’s smart, capable, driven – we know you. We know that you’re working way too many hours, juggling way too many tasks and catching everything that’s falling through the cracks. We are here to help.

We’re also speaking to the managers out there – those of you who have risen up the product ranks. We’re one of you. Being pulled in multiple directions. Working on a product that’s not growing and the team is looking to you. It’s time to go back to the fundamentals. We are here to help.

That’s what our Product Rebellion is all about. Our jobs are to wave that customer flag – every day. Join us.

We commit to giving you ideas, tools, examples that will help in your fight. Join us.

We want you. Your customers need you. Let’s get back to doing the jobs we must, and creating products that customers love.

Join us.

When all else fails – go talk to a customer.

Having a bad day? Got another twenty powerpoint revisions to make for that big meeting tomorrow? The one that seems to come around every 5 minutes… Well, here’s your first rebel challenge. Block two hours tomorrow (and if that’s really not possible, find a time next week). Put it in your calendar now (that’s right, open up your calendar and book it. We’ll wait). Now search through your customer logs and find a customer who’s given you feedback recently. It doesn’t matter if it’s praise, a complaint, or just a question. Send them an email to request a 15 minute discussion about your product. Now do that again two more times with two more customers. You just booked yourself time to talk to three real people about your product. Excited?

Now all you need to do is put this script into your calendar, and you’re all set:

Hi, I’m <name>, a product manager with <name of product>. I know that you recently used our product, and I’d really appreciate hearing a little about your experience. This won’t take more than 10-12 minutes of your time. I just have three questions:

  1. Can you tell me a little about why you chose the product, and is it meeting your expectations? (why, why not)
  2. What would you recommend about the product? (Why)
  3. If you could change one thing, what would it be? (Why)

Thanks so much for your time. Talking to customers is one of my favorite parts of the day, and I so appreciate your willingness to share your experience with me.

That’s it…go ahead and modify it whatever way you prefer. But if you don’t have time, you still have this waiting in your calendar, ready to go. No excuses! Go on product rebel, make a difference to a single customer, and maybe learn something that will make a big difference for you.