Podcast Double Header: Product Marketing and Product Management Metrics

by Saeed Khan

I had the pleasure of being interviewed on two podcasts recently and wanted to share those episodes with you.

The Everyday Innovator

chadmcallisterThe first was on Chad McAllister’s The Everyday Innovator. Chad and I discussed Metrics and Successful Product Management.

Chad and I discussed the Product Lifecycle, both how the focus of Product Managers varies across the lifecycle and how what is important (the key metrics) change. And this fact, that Product Management focus changes across the various stages of the product lifecycle is what makes Product Management both interesting and complex.

The discussion was roughly based on the content in this presentation.

Ready Product Radio

allanneilThe second interview was with Allan Neil of Ready Product Radio. We discussed another topic of interest to me which is Product Marketing and how to optimize it. Interestingly, we also discussed the Product Lifecycle and how the role of Product Marketing changes across the lifecycle. We also discussed organizational structures and the types of metrics Product Marketers can focus on to help them be successful in their roles.

My conversation with Allan was roughly based on this presentation.

I would love to hear your thoughts on either of these interviews; what you liked/disliked, what you agreed with and what you didn’t.


Tweet this: Podcast Double Header:  Product Marketing and Product Management Metrics #prodmgmt #prodmktg

About the Author

saeed-headshot-colourSaeed Khan is a founder and Managing Editor of On Product Management, and has worked for the last 20 years in high-technology companies building and managing market leading products. He also speaks regularly at events on the topic of product management and product leadership. You can contact him via Twitter @saeedwkhan or via the Contact Us page on this blog.

Writing Technical User Stories

By Sogol Fathian

userstoryRecently I gave a talk about writing technical stories and ways I have found to slice user stories thinner at Product Camp Toronto. I thought it’d be good to share some ideas from that talk here as well.

I work as Product Manager for epost which is one of the biggest online document delivery and management systems within Canada. epost allows users to view, pay and manage bills online and roughly one in ten Canadians use it to view their pay stubs, utility bills and tax statements among others. Right now I am in charge of leading a scrum team to redesign epost to improve web and mobile user experience. I am also responsible to revamp epost API service calls and to integrate them with Canada Post, banks and mobile apps.

My team is one of the first teams working Agile within Canada Post, so we are all new to the concept of finishing user stories within a two week sprint. And after the first few sprints I realized that we were constantly behind schedule.

Our flow for getting a story done looked something like the following:


Creating API calls and gateway calls would take half a sprint and front-end will work on the last leg of sprint to get it done. So when the story was ready for QA we were out of time and stories kept piling up to the next sprint!

I also realized during our sprint planning and release planning a bunch of tasks get discovered and brought up that are not identified earlier. By the time these tasks are done, we are already late with the sprint. It was clear to me that I needed to write smaller stories but how?

With a help of a my great Scrum Master Peter Moreira and User Story Mapping (more on this later) I came of with the following strategies.

Write Technical Stories (when necessary)

I decided since any given back-end service call will be consumed by multiple end-points it makes sense to slice a story further into an API-specific one and a front-end/UI one. API story is still valuable and independent (sort of) but it can be estimated and worked on by itself. This way I could prioritize the API story ahead of front-end story to provide much needed time for UI and QA to be done.

This was great however I didn’t know how to write user stories about API, web services and other technical stories that are not necessarily user facing. More importantly I was struggling to fit the story into “As a user I want to — so that I can —” template.

“As a front-end developer I need to supply mail list data so that it shows as a list view of mails” sure sounds weird!

I came across this excellent article that confirmed my belief not to fit the story into a template when it doesn’t fit. So for technical stories I clearly write Who the end-points consumers of the API call will be, What is expected acceptance criteria of each of the end-points are and what it the expected output of this API is and finally Why this API call is important to develop. I talk to developers to understand what does API generate, how it can be validated and make sure there is alignment on acceptance criteria prior to grooming session. From my point the story is usually done once I can see API call and the data generated in Swagger and all the security criteria is met.

So a user story that looked like this before:

—As a Chief Household Officer, I want to filter mail by service provider name so that I more easily find my mail

the API story will look like this:

—We need an API call used by Canada Post, native app and our bank partners to filter mail by a service provider so only mails by that provider shows up

Acceptance Criteria

  • Verify that the request get thru the service layers and receive a reply within 2 seconds
  • Verify that the request has necessary Oauth permission to be exposed externally
  • Verify that the request is generated in both XML and JSON formats
  • Verify that records are returned from oldest to newest

—Separate Success and Error Stories

Another trick I’ve found effective to write smaller stories is to focus one user story only on the happy-path, while writing other stories for when things went wrong, edge cases. For example for file creation user story write one story specifically about creating a file without any problem but write several more stories to cover the file name maximum character, acceptable  characters etc.

I would love to know if you have other ways to slice a story further. Please share them with me in the comments below!

“With corporate and startup experience in various product management roles, Sogol is a passionate practitioner of agile and lean approach to product development. Sogol currently works as a Senior Product Manager redefining web and mobile experience for millions of Canadians interacting with Canada Post daily.”
Tweet this: Writing Technical User Stories http://wp.me/pXBON-4rY #prodmgmt
About the Author
 sogolfathian-headshotWith corporate and startup experience in various product management roles, Sogol is a passionate practitioner of agile and lean approach to product development. Sogol currently works as a Senior Product Manager redefining web and mobile experience for millions of Canadians interacting with Canada Post daily.”

What’s Different about Managing SaaS Products?

By Felicia Anderson

SaaS provides a treasure trove of new user insights.

As customers adopt Software as a Service (SaaS) in record numbers, those software providers that effectively leverage SaaS’ unique advantages will move into industry-leading positions.  Companies that fail to do so will lose competitive ground.

Here are 3 areas that every SaaS product team should consider to make the most of the SaaS opportunity.

Instrument your products to observe true user behavior

SaaS providers have unprecedented visibility into users’ activities.  Product teams should add capabilities to track user behavior quantitatively and use that information to improve the product.  This approach typically yields much better results than activities such as focus groups because it shows what users actually do, not what they say (which is often notably different than what they do).

Intuit, a company renowned for its practice of following customers home to monitor user behavior in a natural environment, got dramatically different results when talking with users about a solution versus silently observing their behavior from within the product.  In one case, they were considering how to improve the onboarding process for new payroll customers.Man 1

Initially, they mocked up screens to show the option of running the first payroll prior to completing the full configuration.  With screenshots in hand, they met with 20 prospects and asked if they would choose the option of running the first round of checks before completing the set up.  Not a single prospect expressed interest in this option.

Then they changed the screen on the actual site to show this as an option.  They didn’t have the backend functionality yet but wanted to test user behavior.  Intuit founder, Scott Clark, recounts that “when they actually didn’t ask an opinion and just watched behavior, 58% clicked, “I want to cut the checks first.” 58%.”[1]

That’s an eye-popping difference:  zero percent interest when talking with the prospects versus 58% interest when presented with the option in the product.  The product team proceeded to add the capability, which resulted in the fastest customer growth for that product in ten years.

Use SaaS’ superior customer feedback options

Great SaaS products enable users to provide feedback within the context of the user experience itself.  With an easy-to-find, simple, in-application feedback capability, users will typically provide more accurate and more useful feedback. Well-designed in-app feedback can reduce customer service cost, increase issue resolution speed, and result in more actionable enhancement suggestions.

Tweet this:  Great SaaS products enable users to provide feedback within the context of the user experience itself

EdX, the nonprofit that provides free online courses from MIT, Harvard and other leading colleges and universities, provides a great example of in-application feedback.  The user goes to the same place for all types of feedback, and the form is very simple and short (just 2 questions, see below).  But possibly the most important feature is that access to the help tab moves with the user so that it is always visible, even when the user scrolls down.  When users have a suggestion or concern, they do not have to scramble to figure out where to go to share their feedback.

EdX Feedback

EdX Feedback Form:  Simple, Short, and Easy to Find

Minimize churn

SaaS industry leaders understand this simple truth:

“the single biggest driver of long term profitability for your cloud business…is the renewal rate of your customers.”[2]

To minimize churn, mine the data from your SaaS user base to identify leading indicators of attrition.   One useful practice is to monitor usage by account to identify accounts that have recently reduced either their log-in frequency or their transaction volume.   These accounts are frequently at risk of churning, so coordinate with sales, professional services, or customer support to intervene prior to losing the customer.

Tweet this:  To minimize churn, mine the data from your SaaS user base to identify leading indicators of attrition

Goldfish2SaaS provides exciting, new ways understand and stay close to customers.  With on premise products, product managers could only speak with and get feedback from a limited number of customers each year.

With SaaS products, on the other hand, it’s possible to glean insights from the entire user base, whether that’s 100, 1,000 or 100,000 users.  Armed with superior information across a broader set of users, product managers of SaaS products can deliver solutions with even greater customer value.


Tweet this: What’s different about managing SaaS products http://wp.me/pXBON-4rH #cloud #prodmgmt

About the Author

felicia-anderson-headshotFelicia Anderson is Director of Program Management, Cloud Services at OpenText.  She helps product teams improve product investment decisions and increase launch success of cloud-based products.




[1]Why Intuit Founder Scott Cook Wants You To Stop Listening To Your Boss, Fast Company, http://www.fastcompany.com/3020699/bottom-line/why-intuit-founder-scott-cook-wants-you-to-stop-listening-to-your-boss

[2] Byron Deeter, Bessemer Venture Partners, http://www.bvp.com/blog/customer-success-company-success


Feeding the product team using “pull”

As soon as somebody says you’re spending too much time on something, you’re on the right track.—Bob Lefsetz, American music industry author.


There are two approaches to delivering stories to your product team: pull and push. Typically, product managers and executives “push” more and more requests to the developers. Even though the team already has a bunch of things, we push another few and then another few and then some more until the team is paralyzed with unfinished work. In more practical terms, the product manager builds a long list of prioritized requirements, perhaps grouping them into themes or releases, and sends the developers a few hundred items at a time. This is probably the most common scenario and tends to have three negative effects.

First, a long list of stories is overwhelming to the team, which damages their spirit and hurts productivity. Second, this approach tends to give you a whole bunch of disconnected stories so you have 80% of everything but not 100% of anything. Finally, pushing a lot of work at one time means you can’t reasonably re-prioritize the work when business conditions change.

Rather than pushing a bunch of work to developers, I prefer to let them “pull” work when they’re available to take on new tasks. In this scenario, the product manager maintains a long list of prioritized work. Developers request more work when they have bandwidth and the product manager hands them the next thing on the prioritized list.

One of the chief ideas of Kanban is to limit the amount of work in progress. Each developer works on one item at a time. They work until they’re done and then ask for more work. The product manager maintains a steady queue of work in queue.


Since the product manager is constantly prioritizing the list, the most important items are always on the top of the queue, waiting for development bandwidth.

Task switching is a well-known detriment to productivity. You want to avoid changing the work that has begun. Never mess with work-in-progress. But since no work is being done on your story queue, you can always add items to the top, bottom or the middle based on their importance.

In one product management job, I was told the development team was terrible; they couldn’t seem to finish anything. Investigating further, I found the problem wasn’t with the developers but with the executives. They were changing the priorities constantly. They didn’t seem to realize that one sentence from the leadership team meant weeks (or months) of work for the product team. I found the developers to be quite competent but with an ever-changing priority list, they couldn’t complete anything before a new #1 priority interfered.

We switched the team from a push approach to a pull technique. We didn’t mess with anything that was in progress. All new ideas went into the product manager’s queue, was prioritized based on business value, and then delivered to development when they needed work. That meant that executive pet projects could be put on the stack and then delivered to the team when the item became a top priority.

It also meant that bugs and architectural stories could be delivered to development just like requests for new functionality.

And when you’re working in short cycles, new important items can be started every week or so. It’s not like we have to wait a month or a quarter to begin a new initiative.

Are you using a “pull” method with your team? Share what’s working in the comments.

Product Management Workshop: Aug. 22-23 in Chicago


Craftsman PM Class Picture

Want to take  your Product craft to the next level? Attend the Craftsman PM 2-day hands-on Product Management workshop.

  • Think holistically about building and marketing The Whole Product
  • Go beyond MVP/Lean Startup and dogmatic frameworks
  • Raise your Product Management game

Details are here:


The Craftsman PM: A 2-day Hands-on Workshop 
Where: Blue1647, Chicago, IL
When: August 22-23 930AM – 430PM both days
Use Code ONPM for a special registration discount just for OnPM Readers!

Tweet this: Product Management workshop – Chicago – August 22-23 2015  –  http://wp.me/pXBON-4rm #prodmgmt