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!!

 

 

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?