An Opportunity Canvas is a simple one-pager I like to use to facilitate a discussion about a new feature or capability. It’s put together in the spirit of the Business Model Canvas or Lean Canvas which are fabulous tools for discussing new products. But, unlike those canvases, the Opp Canvas assumes you’ve got a product already out there so you won’t need to reconsider the operational or revenue model – which is what those other canvases ask you to deal with.
Because we’ve got so many good ideas for features we could add, we should consider the specific user’s problems we’re solving, and how we think they would use your solution to solve them. And, since it’s not only about users, you should discuss how users being challenged hurts your business, and how helping them helps your business. This all helps to figure out how we’ll measure success. The Opp Canvas helps drive that discussion.
I have a fundamental problem when teaching Story Mapping in a class or workshop. That is, participants never have enough time to build a complete enough backlog to explore all the different release and development strategies that having a full backlog gives you. That sucks. But, I have a simple solution.
I’ve borrowed an idea from cooking shows. You know how when you watch a cooking show the chef cuts up and prepares some of the ingredients – but not all of them? Someone behind the scenes and ahead of the show has cut up all the ingredients and got them ready so the chef can just pull them out and mix them in. They may have even cooked up whatever the chef will put into the oven so at the right time in the show, the chef can pull something out of the oven ready to taste. That’s what I’ve done with a couple story mapping problems I use in classes. Basically, I’ve chopped, mixed, and cooked up a small software product. It’s nearly done. But to finish it, you’ll need to add a little of your own effort.
Lists – mobile planning and to-do lists
The lists problem is yet another mobile app to create simple to-do lists, plans, wish lists – or whatever your target users might wish to create. Who your target user is, and what’s in scope is up to you.
You can see a directory of all the lists parts here.
In it you’ll find:
background on the problem
an opportunity canvas all filled out – but with some vague stuff you could improve on
3 possible personas in a 2-column proto-persona format with room for you to fill in your solution ideas
some really rough UI sketches so you can get some ideas what the app could look like – but they’re pretty uninspired. You could do better!
Here’s what it looks like printed and spread out on my office floor.
Film Finder – a place to find info on movies
Yes I know there’s imdb.com and lots of other sites and apps out there… but maybe a trimmer app focused on a particular type of user might find a different niche.
In August 2007 I was lucky enough to be able to edit an issue of Better Software Magazine. I was able to choose my authors: Alistair Cockburn, Jim Highsmith, and Jim Shore. I did this because I was lazy – I wanted great articles without a lot of effort. Choosing these authors guaranteed it.
This “Technically Speaking” column from the editor allowed me a page to rant about what was important to me – namely the tendency for software development to dig too quickly into building software before being clear about the context their software will be used in, the goals it should reach, and the problems it should solve.
Why common Agile processes like Scrum and Extreme Programming can cause startups to focus on the wrong thing
When working with startups individually or coaching in an accelerator, I often get asked to do a basic Agile tutorial. And, every time I’m asked, I get this sinking feeling. What most people believe Agile development is today isn’t at all what you need if you’re a startup. In fact, trying too hard to get Agile “right” is a good way to slow down the stuff that should really be happening.
Common Agile Practice is for Delivery
When most people think of common Agile practice today, they think of this Scrum/Extreme Programming hybrid – or XcrumP as I like to call it. It goes a little like this.
A product owner builds a backlog of user stories that describes your Minimum Viable Product – the smallest product you think will succeed in the market (stories came from XP, backlogs from Scrum).
Prioritize the backlog highest priority first, (which is hard because we need it all, at least we’re pretty sure we do).
Use a Sprint Planning Session to plan the details for 2 weeks worth of work (but we’re hopelessly optimistic so we often over-commit to 3 weeks or more).
Start a 2-week Sprint (Scrum’s name for a time-boxed development cycle, and they could be as short as one week, or as long as a four).
Every day hold a standup meeting (which actually feels like a status report to the people who are stressed because development isn’t moving fast enough).
Every day move sticky notes around a task board (which looks more like a Kanban board).
Try using some sort of tracking tool to track the backlog and progress (and show burndown charts which for some reason people really hate to create by hand).
Use engineering rigor like test-driven development, automated acceptance tests, and continuous integration (but throw it out when it looks like we’re not going to get everything done in time).
As stories are finished coding, the tester thoroughly tests them, and the product owner reviews them (but usually we hand off a pile of finished stories to the tester the last day of the Sprint and tell them to test it all, then watch the tester melt down).
At the end of 2-weeks, stop and do a Sprint Review where we briefly show what we got done, and reflect on how we could improve (but we spend a lot of time arguing about whether things are really “done-done” because we want a high velocity, and then we make excuses for why we couldn’t get 3 weeks of work done in 2 weeks).
Repeat steps 2-10 till done or out of cash, whichever comes first.
That’s the basic flow. And my snarky comments in parens are what I see usually go wrong. And sadly, they may sound way too familiar to some of you.
I remind people often that:
process isn’t skill
Understanding a process isn’t the same thing as doing it well. And, it takes a while to build the skill and discipline necessary to predictably deliver at high quality. But happily with a common Agile process like Scrum, you’ll get to stop and reflect on where you’re really sucking every couple weeks, and you’ll see that get better over time.
Common Agile practice today uses time-boxed development cycles to put just enough structure around the process of planning work, doing work, and then stopping to evaluate and course correct. This simple execution loop uses velocity, or the rate we’re delivering software as its most visible metric. And that makes sense considering of the key Agile principles (mentioned in the Agile Manifesto) is: “+Working software is the primary measure of progress.”
If you’re going to execute well, you’ll need to build these basic Agile muscles.
But all that emphasis on delivery velocity leads people to believe that that’s all Agile processes are about. And when you want more stuff faster, which we all do, that can be a pretty seductive draw.
Agile in the Startup – the Anti-pattern
A few guys in a garage programming day and night stopping only to eat pizza and play Call of Duty.
Is that the mental model you have for a startup? This is the sort of startup where the founders believe their idea is fantastic, so fantastic that their biggest problem is getting their big idea built faster so they can release it to much fanfare at a big launch party. A startup thinking this way might adopt an Agile development approach with the hopes of building faster, or to at least get a bit of visibility into how fast the team is actually going.
Imagine a Silicon Valley startup adopting Scrum so they can go faster. Actually, don’t imagine it. Watch this short excerpt from the HBO series Silicon Valley – but watch out, because there’s lots of “adult language.” (If you offend easily – go back to just imagining it.)
Thanks to my friend Aaron for first showing me this. If you’re in a startup, start watching Silicon Valley for a good “scared straight” experience.
As silly as this video makes Scrum look, the video points out a few of the key benefits of an Agile process like Scrum, benefits like making a plan, and keeping work visible. In the video Dinesh says: “You see what he’s doing right? He’s trying to get us to compete so we work faster…” And, in spite of being mad about being manipulated, the programmers code faster so they won’t be outdone by each other.
OK, all that’s great. But for some of you, you already know that building more faster isn’t really your biggest risk. At least not to start with.
Most Startups are About Discovery
These days, thanks to Lean Startup thinking and Customer Development, we now know our biggest risk isn’t getting the software built, but validating that there are customers out there that want our product, and can use it. I’m going to call that stuff product discovery.
Now I suspect if you’re reading this, you’re familiar with Lean Startup’s build-measure-learn loop, but I’ll explain it anyway – from my perspective.
Describe our big product idea (but recognize that it’s a hypothesis, we can’t assume people want it)
Identify the riskiest assumptions hidden in our product idea (assumptions about who our customers are, and their needs, as well as assumptions about how they’d value and use our product)
Separate out the few biggest assumptions (those that would sink your product if they weren’t correct)
Identify an approach to validating those assumptions – your Minimum Viable Product Test (customers you could talk to, and potentially prototypes or examples they could engage with to validate your assumptions)
Build your simple prototype (and write a few notes about how you’ll engage with customers to test your assumptions)
Engage with customers to test your assumptions (pay attention to what you’ve learned as you do)
Make sense of what you’ve learned, and rethink your big product idea
Repeat steps 2-7 until you’re confident you’ve identified the smallest product you really need to build, or until you’re out of cash
There’s something very different about this process loop: the primary measure of progress during discovery isn’t delivery velocity, it’s learning velocity. And sadly, we can’t measure its features or stories completed. And, even worse, we can’t plan two weeks of it in detail because what we learn today can and should change what we do tomorrow.
When you’re doing discovery right, it could look a little like this team at the Nordstrom Innovation Lab.
Notice the Nordstrom Lab still uses time-boxes, 1 week in this case. But, they didn’t start the time-box by predicting how much they’d deliver, but with learning goals in mind. Then they iterated around the build-measure-learn loop as fast as they could.
What the Nordstrom team ended up with wasn’t really “high quality software” – it was more of a jankety prototype that worked well enough so that they could leave it behind and measure the stuff that mattered most: did sales people actually use the application? Did they actually sell more as a consequence? And, did Nordstrom customers like the experience of buying this way better? Honestly, the jury is still out on all those questions. Notice that you won’t see this application running in a Nordstrom store near you. But that’s not failure. It’s learning. In the words of my friend David Hussman:
“The difference between learning and failure is how much money you spend to do it.” — David Hussman@davidhussman
Discovery teams quickly figure out that what takes the longest time isn’t building working software, it’s getting time with customers in order to learn something that really slow you down. The Nordstrom team solves this problem by placing their small discovery team inside a teaming pool of customers that they could learn from. This allowed them to get around the learning loop many times a day. That’s a super-fast learning velocity.
Keep the spirit of Agile, and discount the dogma
If you’re in software development today, you really need to understand Agile development. But, if you’re a startup, be aware that common Agile practice is about predictable delivery and is best suited for the times when you’re confident you’re building the right thing. By using an Agile time-boxed development cycle, you can more predictably build it right.
If you’re biggest risk is building the right thing, focus on building your learning muscles.
Go back to original Agile values and principles. Remember that Scrum and Extreme Programming are good delivery approaches to using Agile thinking, but not the only approaches. As a team frequently ask yourselves these questions:
Are we working together as a team collaboratively and effectively?
Are we making our ideas visible fast so we can learn fast, whether it’s working software, or a simple paper prototype?
Are we learning directly from our real customers, the people that will buy and use our product?
Are we stopping frequently to take stock of what we’ve learned and to re-think our product idea, our plans, and the way we’re working?
Those four questions are what the manifesto really means from a startup’s perspective. Keep those basics in mind, forget all the other agile dogma you hear, and you’ll be using Agile right.
A simple recipe for using collaborative sketching with Agile and Lean UX teams
Design Studio is a quick collaborative approach to considering lots of possible solution ideas for a new product, a feature, or enhancement.
In a design studio, everyone sketches and shares ideas. By everyone I really mean everyone: UI designers, developers, testers, product managers, business stakeholders, end users, customer service people, and anyone else interested. Everyone feels involved and engaged. Everyone quickly learns that the best ideas aren’t any one person’s but a mashup of everyone’s. And, on top of all this, it’s fun. And, you deserve a little fun. (more…)
Jeff Patton & Associates has designed a fast-paced, high energy event for Product Teams
If a typical course is like learning to swim from a powerpoint deck, our 5-day immersion is like being thrown into the deep end of the pool. But, don’t worry. We’re here with water wings and some good coaching to keep you from drowning.
