Product Scorecard Ranking – out of yellow and into green

Like the political polling map a product scorecard gives senior management a quick overview of where actions need to be focused and which regions we need to invest in. Ideally we’d like everything to be green, but realistically a sea of three colors is what you’ll have to deal with. Let’s break this down into a few steps.

product scorecard

A simple scoring method from yesterday’s post: The Product Scorecard – measure it, so you can manage it

Step 1

Let’s begin to view the scorecard from the previous post like an election map it makes the decision where to focus quite easy – forget about the red areas and try to move yellows to green. From this view we would first believe we would need to move all 11 yellow blocks to yellow. In reality, we need to prioritize and decide which ones are critical, which ones are possible, and which ones we won’t touch.

7 Green areas working as planned. 11 Yellow to rank.

Step 2

In the next step we need to go back to the scorecard details and re-rank the yellow areas in their priority as green, yellow and red. Once this is completed we need determine if the areas are worth the effort, and if we have the resources needed to make this change. This map shows all Step 1 greens grayed out, since there is nothing left to do here, and yellow areas re-ranked from red to green. Now, instead of 11 areas we need to divide resources on we now have a mere 5 areas where we can concentrate 100% of our efforts.

Re-ranking yellow from Green to Red.

Applying this approach to your go-to-market analysis will help you to plan strategies and build better products. And since all the parts of a product go-to-market are tied together, focusing on these 5 areas should move more yellows to green so you are ready for the next product launch.

Artefact: Go-to-market analysis map shown as the United States of the Product. – just for fun!

The Product Scorecard – measure it, so you can manage it

Product baselines are key tool a management team can use to view a product lifecycle because they help a team look at what was done, Good baselines should help a team see what was done right, what we thought was done right, and what we should not do again. These assumptions should help improve the product. The job of the product manager is to present these baselines so that management can make the best decision on direction. Yes a good product manager can as well make these conclusions, but it is not your job. Your job is to gather the most concrete and up-to-date data to ensure the baseline tells the real story. Your job is critical, since it is your presentation that will persuade management. Your job is on the line, since it is your detailed investigation that will rate an effort as done right, done right but wrong decision, or done wrong.

product scorecard

a simple scoring method that describes the stages of a product regardless of complexity

I would recommend that product managers find a simple scoring method that describes the stages of a product regardless of complexity. Then fine-tune this scorecard and use this from product to product to ensure that it is consistent and clear from a management perspective. The scorecard above was created for comparing a single complex product across multiple regions in EMEALAAP. Senior management can quickly assess where things went wrong and where we need to to focus so that we get things right the next time.

“If you can measure it, you can manage it.”  ― Robert S. Kaplan, Strategy Maps

Transition to agile: pre-sprint planning

So, I’ve spent my last days sending out calendar holds, mini 1-on-1s, and completing rough documents that begin scope out the vision and “really big” stories for the project. Since we are approaching the holiday season most of the next weeks will be spent planning and setting up a workspace so we are ready for Sprint 1.

Digital handwriting w/ iPencil

My digital writing is no more legible than pen and paper. 😉

The planning call today covered some basics that we’ll need in this project. As previously stated we won’t run this as a traditional software development sprint, but rather apply agile to an innovation product management sprint, with a cross-function team of 4 core members. I’ve created the checklist below that should help you get things running if you’re new to this process.

  • Define each work streams and verify an owner of eacH – Ours are defined as technology/design, content development and production, business, and marketing
  • Setup pep-talks with the owners, mini 1-on-1s
  • Define a commitment goal for the core group – We won’t be looking this group in a rooo for 2 week sprints so we agreed that a commitment for 35-40% of each persons total time will be our sweet spot. (There is no sweet spot in agile. The goal is for the team to be motivated and be able to deliver in short chunks.)
  • Set a start date and an end date for the first release – we’ve pick a national event in March where key influencers will be. Goal is to create awareness for the pilot project and have influencers recommend it to our target users.
  • Setup baseline configuration – we will be use JIRA
  • Import rough (really big)  stories to start building a backlog, pick a few that may be relevant for the first sprint and analyze these to ensure we have what is needed to put them into the first sprint – budgets, specification, business support, etc
  • Decide how to size stories – points or hours – being a cross-functional team with non-software expertise we’ve chosen to use hours rather than story points.

I hope this helps give some guidance with the pre-sprint planning process. I’m not brand new to agile, but adopting it as a new innovation tool for managing this project introduces some new challenage and hurdles. Feel free to ask me any questions along the way and follow me to stay updated.

So I’ll leave you with two last points that may help you until the next post:

  1. Always just focus on the current sprint – the next two weeks.
  2. Create stories that can be completed to help the team perform at their best.

you may want to read the previous post A Transition to Agile