I was scrolling at speed through my inherited product backlog — dusting off abandoned user stories, manoeuvring around overgrown bugs and hopping over hunches. I was a new product owner emerging from a design and development career. My previous engineering experience had not prepared me for my new role as much as I thought it had. “What are we working on this sprint?” My impatient software team were staring at me expectantly. I’d become a product owner so I could directly shape and create a product that people loved. But there was no love in this room.
..it’s not about…
In the book Competing Against Luck, Clayton Christensen describes how important it is that all processes in an organisation be aligned to the customer’s Job. This enables an organisation to truly deliver on the Job the customer has hired it for. This means aligning the product offering, sales, support and of course marketing strategy to the customer’s Job. In this article, I’ll discuss methods I’ve used to leverage Jobs-to-be-Done in marketing workshops.
And use these insights to shape the message you give customers and when you give it.
Introducing Jobs-to-be-Done (or any new idea or process) to a business can be tricky. Even more so if you’re not in an executive or high ranking position. Here are 10 tips to help introduce Jobs-to-be-Done to your organisation.
The first and most important step is to learn as much as you can. Read Competing Against Luck, practice your interview skills and learn how to activate your findings. And if possible, do it on company time and money. This will make them feel they’ve invested in you. They’ll want to see some return on their investment. Use this to your advantage.
When planning a roadmap, it’s common to see descriptions like “Data syncing for automated emails”, “Finance and billing” and “User onboarding”. Sometimes you might see epic user stories like “When I sign-up to the application, I want to see a tutorial, so I can learn how to use the service”. Innocuous descriptions on little yellow cards and gantt charts.
The problem is, these descriptions are packed with assumptions. They assume knowledge, research and planning. Worst of all, they suggest a solution.
There is little in these examples that can help decide what’s most valuable to users or the business. There’s…
Back in 2001, a bunch of smart people got together on a ski holiday and came up with the Agile Manifesto and twelve complementary principles. These simple documents revolutionised the software industry.
The manifesto describes how to organise a team and prioritises early and continuous delivery of valuable software. It does not describe what you should build, why you are building it or what “working software” is.
Sourced from agilemanifesto.org
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value…