«

»

Feb
02

Product Prioritization Part 1 of 2: A Prioritization Schema

This is a topic that is near and dear to anyone involved in product development and something that spans across both the Product Management and the Engineering/Product Development side.  What I originally wanted to cover in this post was the issue of internal vs. “external” projects and some things to think about when having to prioritizing them.  Of course this requires a precedent discussion around a prioritization framework, so I’ll handle this topic in two parts.  The first will discuss our framework for prioritizing product resources defined as PM and development resources.

A product team’s first job is building a list of impactful projects that can lead to addressing the business’ operational and financial goals.  Ideation is key to some degree, but hopefully these ideas are coming from real conversations with customers. Once that list does appear is really when the work begins:

  • How do you assign the best list of projects across a fixed pool of resources?
  • How do you define a “project” in the right increment?
  • How do you pick the right ones relative to each other?
  • How do you reject ideas, yet still foster the flow of ideas to keep the innovation fire a-burning?
All questions that can vary by company and personality, but there is a separate discussion of lean/agile development that I’ll leave for another post someday.

But once you have your list, the next step is clearly to have a process by which you can compare each idea and prioritize the list in execution order, which means assigning the list to your fixed pool of resources.

Most people have to do this in some way, shape or form in their lives with their to-do lists, spending time with friends or spending money, so it isn’t a high level concept.  But, it is a discipline that is often not followed, which leads to second guessing and other issues down the road.  Remembering that this is a process and not a point in time is critical framing.

As such, documenting the process, the full candidate list and rationale for the final list helps keep the team participating in building the products informed and educated on what the final decision was and why. This takes resources and time and needs to be done right.  I have always used a Program Manager to drive and maintain the process as a neutral third party that sits between Product and Dev.  Maintain the list as a backlog that is visible for everyone to see is also critical as it needs to be consulted frequently.

From there the process can be as follows:

  1. Anyone can submit an idea, small or large.
  2. All ideas are added to a database where they can be edited collaboratively (Confluence, Google Docs, etc…).  We like a combination of the two.
  3. Each project should have the following info associated with it:
    • Project Name
    • Description
    • Justification
    • Timing dependencies
  4. Each project should then hyperlink to any product documentation that further explains business rationale and requirements.  Pictures are worth a thousand words.
    • We use the concept of a minimum “one pager “ for each project, but clearly larger efforts require more strategic analyses and business cases.
    • I really like “business model canvas” framework from Alex Osterwlader as a high level model to star new larger concepts.
    • Clearly all projects need some vetting with live prospects and customers so existing UX and demos are the rule vs. long text documents.  Clearly the Lean Startup stuff applies here in many ways.
    • We are also a whiteboard and camera phone group, but are experimenting with Balsamiq

Then, the fun part, picking the order and allocating scare resources. From a high level there are three grades of projects.

P1
Strong impact projects that are directly meeting business goals and can demonstrate obvious benefits based on strategic goals.  These projects have seen external verification and often times have immediate timing needs.  They can range from vetting a new strategy or concept or starting to build code.  There is also something called P1* which is something that is deal dependent that when it hits becomes a disruption usually without any controversy.

P2
Projects that are important but do not have immediate timing needs relative to P1’s.  Or, their ultimate contribution is smaller relative to a P1.

P3
Ideas are too early for proper definition or that have future timing needs.

The subtext on P1′s get personal.  The person requesting it has to make a very convincing, passionate argument as to why this is a P1.  These ideas need to be pretty obvious as important, which requires a person to make the case.

Inevitabily, the first round will probably end up with too many P1′s.  So, there is usually a second round to cut the P1′s down in number.  So, the passion usually needs to be there to make the final cut.

After that you have your list and depending on your planning cycle, you will repeat this as needed.  It is time for execution and the process to track these projects and manage the next list of projects, which will be covered in a subsequent post.

So this is all well in good for a company showing strong revenue growth in a large market working on projects mostly connected with revenue.  But, what happens when that internal platform you are using becomes so old that no one knows how to work on it and it was put together by a developer who didn’t know Java from Java script?

Well that is the topic of the next post….

Kevin
@squawkt22

 

Comments