Category: Product Management

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 #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 #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,

[2] Byron Deeter, Bessemer Venture Partners,


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  – #prodmgmt

5 Reasons why you should regularly attend your product’s training classes

by Saeed Khan

If you work on a product that requires a training class, your product is way too complex!!!

OK, just kidding.  🙂

computer-training-classIf you work in the B2B space, it’s almost guaranteed that there is a training requirement for your product. The training may be delivered face-to-face in a classroom setting, or over the web with a live instructor, or even possibly as a self-paced recorded course.

Regardless of the type of class, odds are you (PM, PMM, UX Lead etc.) didn’t create that class and almost certainly you don’t deliver that class to customers.

You may have attended the class (once) when you were hired or started working on the product — assuming the product already existed — or maybe never at all if you started early enough and learned it on your own.

Regardless of which situation you are in, you should make it a practice to REGULARLY sit in on your product’s training class.

What do I mean by ‘REGULARLY’?  Well, it depends on a number of factors, but at least once per year, if not 2 or 3 times per year if possible.

If the class is a long class (say 2 or 3 or more days), and it’s difficult to commit those days completely (we’re always pulled into meetings etc) then at least sit in on the FIRST day of the class a couple of times a year. Try to pick classes where there are a good number of students attending.

But WHY? We’ll I’ll tell you.

1. It’s an easy way to meet customers face-to-face

OK, this assumes you have a classroom style training course. And if you do, that great!!! Take advantage of it. Meeting these users face-to-face is a great way to start building a relationship with them. Most classes I’ve seen start with some kind of self-introduction by the students. It’s a good way to learn about who is (will be) using your product and also to introduce yourself to them.

You don’t have to become their friend during the class, but when you introduce yourself as the PM for the product they are learning about, trust me, they’ll remember you. And later, if you reach out to them, they know who you are.

Even if the course is NOT a face-to-face classroom setting — i.e. it’s taught by a live instructor to the students over the internet — you can still introduce yourself and make the students aware of you. Better than nothing I say.

Tweet this: 5 Reasons why you should regularly attend your product’s training classes #prodmgmt #prodmktg by @onpm




If you could take training classes on any topic, what would they be?

by Saeed Khan

As Product Leaders, there’s so much that we need to know in order to do our jobs well. These topics run the gamut from business, strategy, finance, technology, design, research, communication, marketing and more. I’m sure I’ve missed a lot of topics.

So here’s how you can help me help you. 🙂

Fill in the form below and let me know the top 3 topics you’d like to learn more about. I’ve left the answers open-ended, but please be specific if you can.  I’ll stop talking now. 🙂

I’m looking forward to your responses.


Tweet this: If you could take training classes on any topic, what would they be? #prodmktg #prodmgmt