Venture Design Sprints

The Venture Design sprints are a set of one-week iterations you can use to systematically progress your venture. While they’re not hard to understand, applying techniques like design thinking and Lean Startup is tricky. The Venture Design sprints borrow heavily from agile and provide a systematic vehicle for innovation.

These sprints map closely to the Venture Design process. Are you confident you understand your users- A day in their life? What makes them tick? What’s on their A-list of issues (problems)? If not, consider a Personas & Problems Sprint.

Are you sure you have a strong, testable proposition that’s better (enough) than your customer’s alternatives? If not, consider a Motivation Sprint before you invest time, money, and emotional commitment into building software.

Is your product usable? Have you made astute, incremental investments in improving usability? If not, consider a Usability Sprint.

Do you have an important question on approach? A build vs. buy? Component/system selection? If so, consider an Architecture Sprint.

The diagram below summarizes the process:

The sections that follow describe the four sprint types in more detail.

The Problem Discovery Sprint

The thing about agile, and product development in general, is that you can’t create something valuable without a strong understanding of the user. You can kill it on usability, craft great code, work like crazy and end up with well-executed product that’s for a user who doesn’t exist. I’ve done it (at least the part about the non-existent user!)- and it sucks.

This is why I’m so big on personas & problem scenarios (see: Personas Tutorial). Even if you start small, you’ve reframed your discussions around something that’s actionable and testable. You can talk about personas with developers, testers, ops/sysadmin. It’s an excellent vehicle for the interdisciplinary collaboration that’s at the heart of any high-functioning program.

In this sprint, you spend a week with real users creating actionable personas & problem scenarios (jobs, habits that you’ll deliver value against). At a high level the sprint has-
Inputs: questions you want to answer with personas & problem scenarios
Outputs: working, tested personas and problem scenarios

When? Why?

The diagram below summarizes a general process for working with personas:

What?

The five-day sprint looks like this:

The most important part of prepping for this sprint is lining up subjects in advance. Unless you have a place where you can find willing subjects on the spot (very rare), you’ll need to have them lined up in advance to make the timing work. Course 2 ‘Running Valuable Design Sprints’ of my Coursera specialization covers this (see: ‘Agile Development‘ on Coursera). The Customer Discovery Handbook here on the site also has notes on preparing for subject interviews.

The sprint lead will brief the team on the charter for the sprint and (if it’s the first go) the concepts they’ll be using. The rest of the day is focused on a) drafting personas, problem scenarios and interview guides and b) creating a game plan for field interviews the next day.

You’re out talking to subjects! Avoid having to come to the office, but do consider some lightweight communication for lessons learned and progress.

Ditto! More talking to subjects!

In the AM, you’ll still be out talking to subjects. In the PM, you’ll be creating a shared perspective on key learnings and then doing some housekeeping: cleaning up your transcripts so they’re referenceable later.

On day 5, you’ll be drafting ideas for propositions and solutions against your top validated problem scenarios. You’ll close with a set of backlog-ready (implementation ready) user stories and mockup’s.

How?

If you’re interested in doing such a sprint, my Coursera specialization ‘Agile Development‘ has in-depth materials in Course 2.

The detailed agenda is available below in Appendix A.

A template for the sprint charter and working notes is available here: Venture Design Sprint Template.

The Motivation Sprint

When? Why?

Few ideas have done as much to answer the question of how you innovate on a systematic basis as Lean Startup. No, it’s not the right approach to every single question, but, yes, it really does work, avoiding massive waste and team disconnects. The motivation sprint is a great structure for its application.

The basic idea with Lean Startup is to use good old science to improve your economics on determining whether or not you’re on to something valuable.

Start with a strong idea (01)- any practicing scientist will tell you the best way to get to solid conclusions is to start with a strong ideas/a strong hypothesis. If you don’t have solid personas & problem scenarios, I recommend attending to that first (see Personas Sprint).

Then you create your hypothesis or hypotheses (02). I like to put these in the form: If we do [something] for [a certain persona], they will [respond in a certain way]. See the Coursera course or Lean Startup tutorial for more on that.

Then you create experimental designs (03). The key here is to be scrappy and creative. Consider what’s effective given that your objective is learning, not scalability. This is what the ‘Minimum Viable Product’ (MVP) is about. The tutorial above has some MVP Case studies as does the Coursera course.

Then you run the experiments (04), which takes practice and skill. That’s most of the real work of this sprint. On Friday, you consider your conclusions (05) and make a decision on whether you’re on to something or should test something else (06).

Key side note on this: Motivation and usability are different (though related) and should be tested separately. My favorite vehicle for talking about this is the Fogg Curve. If your project is in the early phases, focus on motivation. In practice, you can work through weak usability, but you can’t motivate a user who you don’t understand or doesn’t see value in what you’re doing. (The next sprint is about usability.)

What?

The five-day sprint looks like this:

While the idea with this sprint is to start with a fresh look at your propositions, you may want to lay some groundwork for running what you assume will be relevant experiments. It’s a judgement call: you’ll need to think about how confident you are in the types of experiments you’ll want to run, the residual value of any prep. you do, and how much work it requires. See the ‘How’ section below for materials on preparing experiments.

You’ll start with a briefing on the charter and methods by the sprint lead (or whoever’s prepared) and then use some design thinking techniques to articulate your key propositions. In the PM, you’ll structure your key assumptions (hypotheses) design rapid experiments to test them and create a game plan to run the experiments.

In the AM, you’ll attend to any residual logistics to set the experiments in motion. Following that, you’re running those experiments. There are materials on some experiment/MVP archetypes in both the Coursera material and the tutorial here (see above on prep.).

You’re experimenting!

You’re experimenting!

On day 5, you’ll start by looking at your results, discussing them, and making conclusions based on what you observed. If you have positive signals, you’ll proceed to draft narrative (user stories, sketches) for implementation. If you don’t, consider your next steps (another sprint?) and start preparing them.

How?

If you’re interested in doing such a sprint, my Coursera specialization ‘Agile Development‘ has in-depth materials in Course 2.

The detailed agenda is available below in Appendix B.

A template for the sprint charter and working notes is available here: Venture Design Sprint Template.

The Usability Sprint

When? Why?

Usability is part art, part science, but the science part is pretty material and teams can achieve excellent results with systematic, regular usability testing and a drive to shared understanding. It’s important to have strong personas and a strong understanding of the target proposition, hence the sequence of this sprint.

Equipped with strong user stories and a systematic view of how to achieve usability, this sprint provides for the regular, early testing of usability that is a hallmark of high-functioning teams. The material in the Coursera specialization and the Customer Discovery Handbook rely heavily on Donald Norman’s work on systematic usability, including his 7-steps framework:

The framework is useful for breaking down the assessment of individual user stories and making them readily accessible to a) pairing with established interface patterns and b) phase-appropriate usability testing. The sprint also relies heavily on the usability test plan template in the Venture Design template.

What?

The five-day sprint looks like this:

Kind of like the Personas Sprint, you’ll need to line up subjects in advance to make this work. This means having personas, a screener to validate subjects, and a set of sources for recruiting subjects. See Course 2 of the Coursera specialization (Agile Development) and the Customer Discovery Handbook (section on usability) on this site for more on that.

The sprint lead will brief the team on the charter for the sprint and (if it’s the first go) the concepts they’ll be using. Then you’ll review your key narratives (user stories) and prioritize them. For your prioritized stories, you’ll draft usability tests and interactive wireframes for testing.

In the AM, you’ll complete dry run’s and revisions to your test set up. In the PM, you’ll be running usability tests with subjects.

Running tests with subjects!

Particularly if you’re in the early phases with an interface, you want to test in small batches with opportunities for revision. In the AM, you’ll drive to a shared perspective about your learning’s and make corresponding revisions to your mockup’s and test plan. In the PM, you’ll continue testing with subjects.

You’ll continue your testing through the AM. In the PM, you’ll drive to a shared understanding of your key learnings are revise your designs.

How?

If you’re interested in doing such a sprint, my Coursera specialization ‘Agile Development‘ has in-depth materials in Course 2.

The detailed agenda is available below in Appendix C.

A template for the sprint charter and working notes is available here: Venture Design Sprint Template.

The Architecture Sprint

When? Why?

If you’re wondering about how larger architecture & planing work relates to agile’s emphasis on working software and emergent design, well, yes, there’s a tension there. Most of what you’ll see out there will tell you to use your judgement and err on the side of experimenting vs. big planning.

That said, you’ll run into items like build vs. buy decisions or vendor/component decisions that are relatively major and may warrant some kind of technical review.

While you may find some very relevant material that pairs good (or bad) decisions with your particular situation , there’s so much variation that it’s hard to make general recommendations.

In some cases, a simple story may be better than formulating a sprint. Also, that sprint (or spike in a lot of references) may not need to be 5 days. The overall  task may also be longer than that, though personally I would still advise breaking it into one week chunks.

All that said, there are a few general (not possibly non-obvious) things I recommend considering. They’re described below.

What?

Make sure you have personas and problem scenarios not just for the obvious narratives around user functionality and developer facilities but also the less obvious (but important) personas and problem scenarios. For example, what are the implications for testing? For operating the system and keeping it current? Are there other internal users who need to be able to access the system/component to view or create data? Where is the vendor or project headed and is that congruent with your application?

Preparing the items above will help you focus the sprint and balance that with considerations that may be non-obvious but still important. Get advice from outside parties with direct experience whenever possible and don’t be afraid to make that part of the sprint. Often, but not always, some kind of working prototype is a good output for the sprint. Regardless, make sure you understand the contours of a successful (actionable) outcome before you start.

How?

If you’re interested in doing such a sprint, my Coursera specialization on agile has material on this in Course 2 ‘Running Valuable Design Sprints’.

A template for the sprint charter and working notes is available here: Venture Design Sprint Template.

Appendix A: Detailed Schedule for the Problem Discovery Sprint

This supports the material on the Coursera course ‘Running Product Design Sprints‘. It may not make too much sense on a stand-alone basis.

Appendix B: Detailed Schedule for the Motivation Testing Sprint

This supports the material on the Coursera course ‘Running Product Design Sprints‘. It may not make too much sense on a stand-alone basis.

Appendix C: Detailed Schedule for the Usability Sprint

This supports the material on the Coursera course ‘Running Product Design Sprints‘. It may not make too much sense on a stand-alone basis.

Appendix D: Notes & Presentations for Sprint Kickoff’s

If the colleagues joining you in the design sprint are doing the Coursera specialization with you, you may not need this material. Assess whether your team has a solid understanding of these questions and, if so, I’d say skip it.

The Problem Scenario (and Personas) Sprint

Here are the questions I recommend answering for your team, assisted by the deck below (skip whatever you’ve covered already):
What is the Venture Design process? How are we using it?
What steps (from Venture Design) are we focused on right now in the project?
What’s a design sprint and how are we using them?
How will this approach help us avoid waste and get to a successful outcome?
What’s a persona? A problem scenario? How do we develop and use them?
How do problem scenarios pair with alternatives and why is it important to understand that?
What are things we can vs. cannot effectively learn through these types of interviews?
What are the most important practices for doing customer interviews (ex: moving from general to specific questions)?
What are the key target outcomes for the design sprint?
How are you going to be spending the five days?
What is the focus of our particular sprint?

Note: I would hold off talking about the subjects you have available until you start transitioning to next steps and planning for Tuesday. This is to avoid biasing the team as you brainstorm personas.

The Motivation Sprint

Here are the questions I recommend answering for your team, assisted by the deck below (skip whatever you’ve covered already):
What is the Venture Design process? How are we using it?
What steps (from Venture Design) are we focused on right now in the project?
What’s a design sprint and how are we using them?
How will this approach help us avoid waste and get to a successful outcome?
What is Lean Startup? How do you apply the scientific method to innovation?
How does this kind of testing work in practice?
What is an MVP? How have companies applied those?
What are the key target outcomes for the design sprint?
How are you going to be spending the five days?
What is the focus of our particular sprint?

The Usability Sprint

Here are the questions I recommend answering for your team, assisted by the deck below (skip whatever you’ve covered already):
What is the Venture Design process? How are we using it?
What steps (from Venture Design) are we focused on right now in the project?
What’s a design sprint and how are we using them?
How will this approach help us avoid waste and get to a successful outcome?
What’s the best way to think about usability? What language do we use?
How will we know where to focus in our testing?
How do we do the testing?
How do we create prototypes to test?
How do we tie together our user stories, prototypes, and the test plan?
How are you going to be spending the five days?
What is the focus of our particular sprint?

The Architecture Sprint

This one’s a little different than the others. There’s so much possible variation on what you may want to do in this sprint type, it’s not necessarily a 5 day sprint. It might be shorter, longer, or a story that’s in a backlog with other stuff.

That said, since implementation should come in when and only when you know what would deliver value, I think it’s worth reviewing the process (if that’s new to parts of your audience) and what you’ve learned. I also think it’s worth considering a design/story writing workshop with your whole team where you dig into the non-obvious considerations (via narrative) for the architecture goals you’re vetting.

All that said, here are the questions:
What is the Venture Design process? How are we using it?
What have we learned so far? Why is it time to start building stuff and what’s a valuable outcome?
What problems do we want to solve with this architecture sprint?
Who are all the relevant personas that those problems tie back to?
Which of the above are most important?
What are the user stories?
Where can we look for comparable solutions to these problems?
What is the best way to test possible solutions? Does prototyping make sense?