Product Owner Turbo Boost – 3 Things Product Owners Should be Doing besides SCRUM

PO Turbo Boost

I grew up watching Knight Rider, an 80s classic starring David Hasselhoff as Michael Knight, a vigilante assisted by KITT, a bullet proof talking car.  The premise of the show was simple – Michael Knight would spend the first 75% of the show getting into trouble by investigating crimes and looking for clues that would lead to the correct answer, but when he encountered the bad guys/difficult circumstances, he would hop into KITT and push Turbo Boost!.  Upon pushing the button, all the bad guys got taken out in a multitude of glorious ways.  Good guys win.

As a product manager, I’ve felt like Michael Knight – in search of clues to get to the correct answer, but oftentimes stymied by all sorts of bad guys / difficult circumstances. Unfortunately, for a product manager, there is no Turbo Boost button to get me out of a jam.

The job of a Product Manager is a role that is never the same in any two organizations. Although there are certifications (Scrum Product Owner) available to help standardize the development aspects of the job, there is a significant portion of the role that isn’t standardized. (Product Manager)

A successful product manager must not just be content being a SCRUM product owner.   When you’re able to figure out the part of the job that isn’t standardized, that’s when you can turbo boost your product management effectiveness and organizational results!

Things a Product Owner Does (according to SCRUM):

  • Meetings – The job of a product owner requires you to attend multiple meetings with your dev team.  You have to attend stand ups (1.25 hrs/week), backlog grooming (1 hr/week), sprint planning (2 hrs/week), and a retro (1 hr/week).  This is about 5.25 hours per week, and if you are running two teams (which is a typical utilization), that’s 11 hours per week in meeting time alone.
  • User Stories – In addition to meeting time, a product owner should also be writing user stories and acceptance criteria.  Writing quality user stories involves taking a large project/product, defining a strong unifying vision, and breaking it down into concrete stories/tasks for a dev team to work on.  A good product manager who knows their domain should be able to do this at a rate of about 1 hour per story if done with care, and it’s typical for a SCRUM team to be able to between 2-5 stories every 2 weeks.  So to stay ahead of the game, a successful product owner who is running 2 dev teams should writing a little more than 5 user stories a week, rounding up to 6 hours a week (if you account for longer term planning/coordination with other PMs) of “story writing.”   Obviously a product owner should try to do more, but there are limited benefits to defining an impeccable backlog and vision that your team will never get to.
  • Clarification of stories – there are times when your stories, as well intended as you wrote them, weren’t good enough for an engineer to use, or the engineer needs to make a trade off and needs some additional context / clarification from you.  In this case, the job of a Product Owner is to make sure they understand what the engineer needs and provide clear guidance to them.  This happens over and over again in tiny conversations and continual dialogue with your dev team, but let’s estimate the amount of conversation and decision making here at around 3 hours per week, assuming you’re collocated with them, having daily stand-ups already, and weren’t just lobbing requirements at them without actually knowing what you’re asking for.

Total – Adding meetings and story-writing time together is about 20 hours a week of work for a product owner who is running two teams, which is where we try to stay under.  But there’s 40 hours in a work week.  What should they be doing with the other 20 hours in the week?  This is where SCRUM falls silent and your shiny CSPO certification is pretty much worthless.  What’s a PO to do?

Things Product Owners should be doing – besides SCRUM:


For entry level PMs – learning.  entry level PMs usually don’t have sufficient knowledge or street cred for their product, technology, or domain that is required to really write stories efficiently or in a cohesive manner.  Sure, they might have their CSPO certification but there’s a difference between knowing how to participate in a process vs. having mastery of a particular subject.  This time is usually spent attaining that mastery of a domain by talking to other experts on your team, learning from them, and borrowing their credibility so that you can speak expertly  about your product domain.  Deliverables for this learning/training process might be:

  • architecture / whiteboard  meetings
  • gathering customer feedback directly from customers or from sales
  • market research and competitive intelligence white papers
  • getting data dumps from various systems and teams
  • analyzing data, identifying key business drivers, modeling, and devising KPIs

For mid-level Product Managers – Synthesis and Optimization.  Mid Level Product Managers are usually starting to get a better handle on their product/market fit.  But just as important as the product/market fit is the cross-dimensional impact of a product.  How will it affect sales? customers? revenue? profitability? sales? marketing? operations? support?  Coming up with suitable KPIs for each of these considerations and ensuring that the impact is understood to each of them is what separates an entry level PM from a mid-level PM.  Devising and implementing strategy that achieves the most optimal outcome for all of these metrics and impacted stakeholders is the core part of the PO role.  Deliverables for this type of work:

  • decision/prioritization matrices
  • operational impact assessments and runbooks / M&Ps
  • decision making and socialization of key decisions
  • models, charts, and reports

For  Senior Product Managers and above – selling and evangelism.  Senior Product managers should know what the best outcome is for the company and for all stakeholders.  They’ve done their homework and made strategies and plans.  However, the hard part of the job is now to convince everyone in the industry (internal stakeholders as well as external customers) that your plan is the best plan, and that everyone needs to get on board.  This is hard.  Deliverables for this type of work:

  • drawing an appropriate narrative from your data
  • candid conversations with key influencers and leaders
  • anticipation of key objections to your plans and developing responses to those concerns
  • building alliances, coalitions, and bases of support for what you wish to accomplish
  • “alignment meetings”
  • meeting with customers and convincing them why your solution is better for them than what they are asking you for



So if you find yourself getting mired down in the Product Development aspects of the Product Manager role – try refocusing your time in one of these three areas and see if you can turbo boost your results as well!  If you’re leading a product organization, take a hard look at your team and see whether you have the right people filling the right roles – learning, optimizing, evangelizing.

  • It’s easy to hire senior people because they have a strong knowledge base or technical skillset, however if these people can’t sell/evangelize their vision to anyone else, then they’re not going to be successful as a senior level product manager – you’ll just end up with a consultant.
  • Likewise, it’s easy to overlook entry level / junior folks who don’t have a skill-set or knowledge base of your industry, but if they can be persuasive and influential within an organization, then they can be trained/coached into being effective.
  • It is essential to have strong leaders who are able to teach, mentor, and coach more junior folks in the organization and also to have programs in place to systemically recruit and train new team members (internships, training, 80/20 programs, career ladders, entry-level programs) along with promote/coach out existing team members into other leadership/operational/industry roles.  This takes a strong culture and a willingness to deal with fluidity within your organization, but in the end  will help establish a highly effective team that you can be proud of.