PRODUCTHEAD: When did storytelling become so hard?
PRODUCTHEAD is a regular newsletter of product management goodness,
curated by Jock Busuttil.
“Requirements” is another way of saying “just shut up and build it”
A user story is deliberately sparse on detail to provoke a team conversation about the user’s goal
We often incorrectly assume everyone does something the same way
The mental model to describe epics, user stories and tasks can be clarified with visual artefacts
User stories often come up as a source of dysfunction in an organisations — often the ones beginning to dabble with Agile methodologies without any clue about the underlying “why” of their newly-adopted practices.
Recently I was helping a lone product manager who was struggling to write enough user stories to keep an overly-large engineering team stocked with stuff to build. This is wrong on at least three counts:
1. It’s the whole team’s responsibility to write user stories collaboratively, not solely the product manager’s. The user story itself isn’t the important bit, it’s the conversation about it with the team that leads to the more important shared understanding of the underlying user goal.
2. In my view at least, engineering teams should be split down into smaller squads, each with its own product manager. Those squads should then collaborate efficiently to ensure their respective work dovetails together nicely. (Note: this is most certainly not SAFe.) A monolithic engineering team of 20+ people smacks of a failure to break down the complexity of a product into smaller, simpler chunks.
3. A large engineering team that only sees value in building (and not research, experimentation and learning) sounds suspiciously like the Head of Engineering is desperately trying to justify their recent overzealous recruitment drive by ensuring their team always looks busy. Stop and work with the rest of the multidisciplinary team to figure out what people need and why before building at great expense a bunch of stuff nobody needs.
So this week I’ve pulled together some helpful content about how to make user stories more effective in your organisation.
Speak to you soon,
what to think about this week
In this podcast episode, Jeff Patton shows us how to use Story Maps to create a shared understanding of a feature and create thin slices that relate to the minimum viable product and additional releases. Jeff also shares his thoughts on the proper way to use User Stories and how to avoid some common pitfalls with User Story Mapping.
BONUS: a PDF quick reference of Jeff’s main points about user stories
[JEFF PATTON / MASTERING BUSINESS ANALYSIS]
When I first came across user stories over 15 years ago, I was surprised by their lack of detail. I was used to working with use cases, and it took me a while to get my head around their sketchiness. They seemed less like requirements and more like notes. And that’s exactly what stories are meant to be — notes that capture the essence of a conversation.
Whether you’re new to product management or have been a product manager for years, a coaching session can help you to step up your career.
We’ve coached people wanting to get into product management, product people with nobody in their organisation to manage them, and experienced product managers preparing to apply for a promotion.
A proportion of the fees from every coaching session is donated to charity. Just reply to this email if you’re interested in finding out more.
Everyone makes toast the same way right? Nope. How many ways could there be to make toast, you might ask. Turns out there are many. And herein lies the power of collaborative visualization. All of us make assumptions about how the world works, how our customers behave or how a system should behave based on our experiences, cultural biases and upbringing. We assume everyone does it the same way — especially the simple things.
Less experienced teams tend to get tripped up trying to define Epics, User Stories, Task, and Sub Tasks. The reality is that software product development is typically one big nested hierarchy, and a super messy one at that. Additional tools — like maps, canvasses, designs, wireframes, logic diagrams — are needed to hold the mental model together.
We enjoy stories because they engage and entertain us more than a simple list of details would. Our brains are wired to remember stories more easily, allowing us to share them with others more easily.
[I MANAGE PRODUCTS]
I am searching for a career change and Product Management/ Project Management are my areas of interest. I was looking to understand, based on your experience, if in such roles technical skills are required?
[I MANAGE PRODUCTS]
Starting a new product manager job can be daunting, particularly if you don’t change jobs very often. I work freelance, so I find myself in a new organisation roughly every 3-6 months. Let me share with you my tips for your first few months in a new role.
[I MANAGE PRODUCTS]
Should the product manager have some level or perhaps a great deal of responsibility for the profitability of the product? Should they understand things like the unit economics, that sort of thing?
[I MANAGE PRODUCTS]
upcoming talks and events
5th May 2021, 16:00 GMT
Online product management round table discussion (topic TBC)
can we help you?
Product People is a product management services company. We can help you through consultancy, training and coaching. Just contact us if you need our help!
Helping people build better products, more successfully, since 2012.
PRODUCTHEAD is a newsletter for product people of all varieties, and is lovingly crafted from unenticing food from the 1980s.
Subscribe to PRODUCTHEAD
PRODUCTHEAD is my free curated newsletter of the best articles, videos and podcasts from product leaders and commentators all over the world. All neatly packaged up in a weekly email delivery for your reading, viewing and listening pleasure.
Read more from Jock
The Practitioner's Guide To Product Management
by Jock Busuttil
“This is a great book for Product Managers or those considering a career in Product Management.”— Lyndsay Denton