I’ve been diving into different product management – importance of roadmap and product prioritization and then a RICE framework for prioritization. Today, wanted to jump back in but look at story mapping. I haven’t done a story map before, but I’ll share what I’ve found reading up on several sites including Aha!, MANIFESTO, Agile Velocity, ThoughtWorks, and others.

The benefit of story mapping is its effectiveness as a visual tool to organize the development tasks and activities with goals – the stories a product/ service user traverses. It prioritizes for value and aligns the team on value and goals.
How to think of story mapping – my preferred route:
  • There are two axes – from left to right, the goals a user accomplishes to achieve a greater goal (e.g. make a purchase, stream a video, other). From top to bottom, the prioritization of stories (activities/ tasks) organized into a release schedule.
  • At the top level, you have the intermittent goals a user achieves. All tasks and activities that help accomplish this goal fall under. For streaming a movie on Netflix, for example, the top-level goals, these can be: “Find movie”, “Assess movie (details)”, “Select movie”. 

  • Under each goal would be the activities to accomplish the goal – the stories a user undergoes. For example, under “Assess Movie”: “View movie trailer”, “View movie description”, “View critics rating”, “View user rating”.
  • Take an iterative approach to the story map where developers, product managers, and customers review the stories for gaps… adding missing stories and removing redundant stories.
  • Evaluate which stories are critical for the first release – this may create the “MVP”. You could prioritize stories by “MUST”, “SHOULD”, and “COULD”. Assessing the stories, you could draw a line that demarcates the stories into the releases (or MUST, SHOULD, COULD).

  • Utilizing Post-It notes is a fantastic way to create these maps offering flexibility and color-coded stories, goals, etc.
  • Keep story maps focused on achieving specific outcomes and performing specific tasks for a target persona. Then, create other story maps as needed.

These are the highlights of utilizing story mapping in the realm of product management. It’s an effective route to hash out the activities to accomplish a user goal.


What are other methods for managing product development?

Building a business with a product is fun. It’s also a long, difficult journey. That journey of developing a product that includes the many twists and turns of building features, sunsetting features, and the like is called a product roadmap. However, like a traditional map, each road leads to a decision point. In the product world, this is where product prioritization comes into play.
Early on in a product’s lifecycle of a business just starting out is the vision of its founders. The term “MVP” may be tossed around meaning “minimum viable product” as coined by Eric Ries in The Lean Startup. At its core is the prioritization of the key features that will generate the most value and demand in the market as quickly as possible – read: as minimal resources as possible.
But once initial traction takes off (or perhaps doesn’t), there’s a myriad of choices a startup can take in its product journey. This is where the importance of product prioritization comes in. Why is product prioritization so important?
  • Most folks enjoy the creation of new ideas, not necessarily incremental improvements to existing features/ product(s).
  • Development can take on the personal interests rather than based on the impact and influence of another.
  • As a partof the shield to guard against the “Next Feature Fallacy” where the idea that “this” new feature will improve traction, sales, etc.
  • To align cross-functional teams on not only the impact, but the efforts required by all to produce XYZ changes.

Really, the key is being able to optimize for value based on limited resources. Product prioritization requires objective measuring to ensure the most valuable product, and thus company, is created.

Leaning on Des Traynor’srecent talk “Lessons Learned In Growing A Product”, I want to highlight Des’ message on starting out very focused and simple. Des cited Gall’s Law around systems theory to build a successful company.

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system. – John Gall (1975, p.71)**

I’ve written plenty of times about starting very focused including a chapter in Postmortem of a Failed Startup titled “Start Small and Targeted and KILL IT.” I believe it’s the smartest, quickest, and cheapest route to building a successful product/ company.
Some key points from Des about starting simple:
  • “Insanely big ideas should start insanely small”
  • Salesforce’s website started way back in the day with two calls-to-action/ messaging: “Free trial/ membership” and “Forecast the Pipeline”
  • “Start not where successful companies are, but where they started.” This point resonated with me greatly, too, because many big, successful companies tend to start very small solving a major problem. Over time, its breadth of products and services grow pushing complexity and pricing beyond many companies (especially smaller). This creates a gap for new players to come in simple, small, and focused. (And thus, the circle of life…)
  • When you know the problem well, distill to workflows which you build features to enable
  • “A small list of ‘target users’ beats a big list of non-customers”. This point goes into the importance of knowing your audience and solving their real pains.

There are lots more good points from Des’ talk to which I highly recommend you check out.

What are some of your take-aways from Des’ talk? Any of these messages resonate with you? Why?
** Note: John Gall was an American author and pediatrician who wrote in 1975 a book, General systemantics : an essay on how systems work, and especially how they fail….
I watched one of Intercom’s cofounders, Des Traynor, give a talk “Lessons Learned In Growing A Product”. It was instantly one of my favorite talks giving a bit of conceptual, visionary/ motivational, and technical.
One of the tenets that really resonated with me was “be insanely diligent about roadmap”. He talks about how most new features are flops, and shares good practices in diligence. Here are some of the key points:
  • Understand the relationship between how often people use a feature to how many people use the feature. He illustrates a chart with “frequency of use” on the y-axis and the “number of users” on the x-axis. The features with high frequency and many people using them represented the core features
  • When improving features, consider improvements (“change”) in quality, importance, satisfaction, and frequency
  • To motivate more use, consider creating: habits, triggers, rewards, defaults, context, and, generally, more uses
  • When launching a product: “exit by feature set or by a deadline, but above all, exit”. The point here is you can go on and on trying to develop a product, but launching enables testing and market traction

There are a ton more golden nuggets in Des’ talk to which I’ll likely spread out over the next couple blog posts. (Yes, I enjoyed it that much.) I highly encourage everyone watch it, even if you don’t know much about startups or technology.

Having done sales and product management for a little while with startups including my own, I’ve realized how much “likes” mean little in the way of actual usage and conversion. 
I’ve heard plenty of times how prospects “like” a product or service, but then these leads go cold. Or a trial sign-up that never converted. What sounded like sure-wins were not at all. (This is why I get excited about a sale only after two weeks have passed since the check’s cleared.)

A lot can influence these gone-cold leads from poor marketing that gave the wrong expectations, lack of sales diligence and perseverance, competitive products and services, etc. 

You can sense a prospect’s buying interest by his emotion and his engagement in a conversation. I compare the “you have something here” or “I like how this does that” to the social media “Like” button. The term and the “feeling” is fleeting and seldom means anything of real consequence. 

Instead, as a salesperson, as an entrepreneur, as a product engineer, etc., we should be chasing love. We should be doing what we can to generate love for our product or service. Taking a few words from Sam Altman’s (President of renowned startup incubator Y Combinator) Startup Playbook:

Your goal as a startup is to make something users love. If you do that, then you have to figure out how to get a lot more users. But this first part is critical—think about the really successful companies of today. They all started with a product that their early users loved so much they told other people about it. If you fail to do this, you will fail. If you deceive yourself and think your users love your product when they don’t, you will still fail.

Love comes from actual engagement and use of a product. Love comes from solving a real pain point… a “hair-on-fire” problem. It drives prospects to buy and users to engage. It creates word-of-mouth marketing and social proof. Love is the foundation of successful companies.

Though, can you turn all those “likes” you get into love?