Category: Agile

Book review: Sprint (Part 3 – Day 2)

marcabraham1 Comment

Once you’ve set a target as part of Day 1 of your sprint, the next step is for you and your team to look at solutions. On the second day of the sprint, you’ll be coming up with solutions, and sketching them. This day consists of two key activities: (1) review ideas to remix and improve, and (2) create solution sketches to feed into your plan for a prototype and customer testing.

Remix and Improve

In “Sprint”, Jake Knapp, John Zeratsky and Brad Kowitz suggest a good technique to collate and assess ideas: Lightning Demos. With this exercise, your team will take three-minute tours of their favourite ideas or products: from other products, from different domains, and from within your own company. The idea here is to encourage the team to throw everything in the mix, but to do so in a short and snappy way. Each person who has suggested an idea will do a three minute demo, showing the team what’s great about his or her solution. As a facilitator, you might want to use a timer to make sure each team member sticks to the their three minute time slot.

The key thing with these three minute ‘lightning demos’ is that you capture the big ideas from each presentation. Start by asking the person who’s doing the tour, “What’s the big idea here that might be useful?” You can then make a quick drawing of this big idea, write a simple headline above it and add the source underneath. I’ve included an example of a way to capture big ideas in Fig. 1 below.

Fig. 1 – An example of capturing ‘big ideas’ from lightning demos, by Karsten Neben – Taken from: https://medium.com/@karstenn/what-we-learned-in-just-5-days-our-design-sprint-report-b9ada5b7f19a#.27wb5fv4e

Lightning Demos

 

Sketch

In the afternoon of the second day of your sprint, the focus is on coming up with solutions. Instead of doing collective brainstorming sessions – which in my experience run the risk of becoming shouting matches or can be dominated by very vocal people – Knapp, Zeratsky and Kowitz suggest each team member coming up with ideas on their own. People will work individually, thinking about and sketching solutions. I’ve included a simple example of a sketch in Fig. 2 below.

The sketches that people create will act as an important driver for the rest of the sprint. On Wednesday (Day 3), you’ll critique everyone’s sketches and pick the best ones.

If you’re worried about the quality of your sketches, don’t! Knapp, Zeratsky and Kowitz introduce the four step sketch technique. This approach makes it easy for everyone to take some rough solutions and turn them into a detailed solution sketch (see Fig. 2 below):

  1. Notes – As a first step, the team walks around the room and takes notes from looking at all the post-it notes, whiteboards, flip-charts that you have collated over the first day and a half of your sprint.
  2. Ideas – Each team member individually will look at his or her notes and jot down rough ideas, simply filling a sheet with doodles, headlines, etc. The aim here is not to come up with fully fledged ideas or solutions. It’s purely a way for each person to drop down their thoughts.
  3. Crazy 8s – Crazy 8s is a fast-paced exercise. Each person will take his or her strongest ideas and rapidly sketches eight variations in eight minutes. What I like about Crazy 8s is that it stops you from dwelling on your first possible solution for too long. Instead, the eight minute deadlines forces you to quickly decide whether to move on from your first reasonable solution or to stick with it but iterate (see Fig. 3 and 4 below). I’ve found Crazy 8s to work particularly well if you end up sketching several variations of the same idea, exploring alternative versions. Similarly, you can use Crazy 8s to refine a marketing headline or messaging.
  4. Solution sketch – The solution sketch is each person’s best idea, put down on paper in detail. Up to this point, each team member will have worked individually on creating notes, ideas and Crazy 8s, and won’t have shared anything with the rest of the team. This all changes with the solution sketch; each solution sketch is an opinionated hypothesis for how to solve the challenge at hand. These sketches will be looked at – and judged – by the rest of the team. They will therefore need to be detailed, thought-out, and easy to understand (see Fig. 5 and 6 below).

Once each team member has put together a solution sketch, the sprint facilitator will collate them all and put them in a pile. The team will only be allowed to start looking at these solution sketches on the third day of the sprint.

Fig. 2 – Four step sketch technique – Taken from: https://www.fastcodesign.com/3057076/google-ventures-on-how-sketching-can-unlock-big-ideas

4-stage sketch

Fig. 3 – How to do Crazy 8s – Taken from: “Sprint”, pp. 112-113

  1. Each person begins Crazy 8s with a single sheet of letter-size paper.
  2. Fold the paper in half three times, so you have eight panels.
  3. Set a timer to sixty seconds.
  4. Hit “start” and begin sketching – you have sixty seconds per section, for a total of eight minutes to create eight miniature sketches.
  5. Go fast and be messy: As with the notes and ideas, Crazy 8s will not be shared with the team.

Fig. 4 – Crazy 8s example – Taken from: https://www.fastcodesign.com/1672917/the-8-steps-to-creating-a-great-storyboard

1672917-inline-crazy8s

Fig. 5 – Important rules to keep in mind when creating a solution sketch – Taken from: “Sprint”, pp. 114-118

  1. Make it self-explanatory – Your solution sketch needs to explain itself. Think of this sketch as the first test for your idea. If no one can understand it in sketch form, it’s not likely to do any better when it’s polished.
  2. Keep it anonymous – Don’t put your name on your sketch, and be sure that everyone uses the same paper and the same black pens.
  3. Ugly is okay – Your sketch does not have to be fancy (boxes, stick figures, and words are fine), but it does have to be detailed, thoughtful, and complete.
  4. Words matter – Strong writing is especially necessary for software and marketing, where words often make up most of the screen. So pay extra close attention to the writing in your sketch. Don’t use “lorem ipsum” or draw those squiggly lines that mean “text will go here.” That text will go a long way to explain your idea – so make it good and make it real!
  5. Give it a catchy title – Since your name won’t be on your sketch, give it a title. Later, these titles will help you keep track of the different solutions as you’re reviewing and choosing. They’re also a way to draw attention to the big idea in your solution sketch (see the example in Fig 6 below).

Fig. 6 – A solution sketch from Blue Bottle Coffee’s sprint; each sticky note represents one screen – Taken from: https://www.fastcodesign.com/3057076/google-ventures-on-how-sketching-can-unlock-big-ideas

Sketch example

Main learning point: The second day of the sprint is very solution oriented. Instead of long brainstorm sessions, the day is filled with more individually oriented activities, encouraging team members to think about ideas and to come up with their own solution sketch.

Related links:

  1. https://www.fastcodesign.com/3057076/google-ventures-on-how-sketching-can-unlock-big-ideas
  2. https://www.youtube.com/watch?v=_ITJ5lAXQhg
  3. https://medium.com/@karstenn/what-we-learned-in-just-5-days-our-design-sprint-report-b9ada5b7f19a#.atwi36cd7
  4. https://library.gv.com/the-product-design-sprint-diverge-day-2-c7a5df8e7cd0#.7zmlxd9aq
  5. http://www.yaellevey.com/blog/how-to-use-crazy-8s-to-generate-design-ideas/
  6. https://www.fastcodesign.com/1672917/the-8-steps-to-creating-a-great-storyboard

Book review: Sprint (Part 2 – Day 1)

marcabraham3 Comments

In my previous post I started looking at doing 5-day sprints to discover and test solutions for a problem that you’re trying to solve. This follows my reading of “Sprint” by Jake Knapp, John Zeratsky and Braden Kowitz. Once you’ve set the stage for a sprint, it’s time to kick things off: the first day of a sprint is all about agreeing on the challenge that you’re looking to have tackled by the end of the sprint. On the Monday, i.e. the first day of the sprint, the focus is on the following activities: (1) agreeing on a long-term goal (2) making a map of the challenge (3) asking experts and (4) picking a target.

Agree on a long-term goal (‘start at the end’)

You start the sprint by asking the the team “why”, make sure everyone is on the same page about what we’re trying to achieve. Why do we want to create this product? Why are we doing this project? Why do we want to solve this problem? Where do we want to be in 3 months, 6 months, 1 year, even 5 years from now and why? What will success look like? Agreeing on a long term will bring the answers together in a shared purpose.

Once you’ve got a shared understanding of the underlying “why” and have set a long-term goal, you come up with number of specific sprint questions, which you can derive from the assumptions and questions that the team might have. To get the team thinking about some of these questions, you can use the following prompts:

  • What questions do we want to ask in this sprint and why?
  • How will we subsequently utilise the answers to these sprint questions and outcomes?
  • To meet our long-term goal, what has to be true?
  • Imagine we travel into the future and our product or project failed. What might have caused that failure? How can we best mitigate this risk?
  • To reach customers for this product, what has to be true?
  • To deliver value to these customers, what has to be true?

Fig. 1 – Sample long term goal and sprint questions:

Long term goal: More people buying snacks online.

Sprint questions:

  • Are people looking to buy snacks online?
  • What is the experience customers are looking for when buying snacks online?

Map the challenge

Challange Map

Fig. 2 – Example of a Challenge Map: Flatiron Health’s clinical trial enrolment map – Taken from: https://zapier.com/blog/google-ventures-design-sprint/

Creating a map is a great way to understand the steps the customer has to go through to achieve a desired outcome (see a good example in Fig. 2 above). Each map is customer-centric, with a list of key actors on the left. Each map is a story, with a beginning, a middle and an end. These are the common elements of a Challenge Map:

  1. List the actors (on the left) – The “actors” are all the important characters in your story. Most often, they’re different kinds of customers.
  2. Write the ending (on the right) – Write the outcome that the customer wants to achieve.
  3. Words and arrows in between – There’s no need for any fancy drawings; the map should be functional, and simple boxes and arrows should suffice.
  4. Keep it simple – Your map should have from five to around fifteen steps. If there are more than twenty, your map is probably too complicated.
  5. Ask for help – As you create the map, you should keep asking the team, “Does this map look right?” or “What are we missing?”

Ask the Experts

Nobody knows everything and it’s therefore critical that you engage with a range of ‘experts’. One of the biggest challenges of running a sprint is that you’ve got to gather a lot of information and make sense of it in a relatively short space of time. Having short conversations – approx. 30 minutes per conversation – with experts will help massively in collating relevant detail quickly.

Pick a Target

Selecting one target customer and one target event is the final activity of the first day of the sprint. The Decider needs to decide on the target customer and the customer event. Whatever she chooses will become the focus of the rest of the sprint – the sketches, prototype, and customer interviews all flow from this decision. Naturally, this can be a group decision, but it helps to assign decision-making responsibility to a single person.

Once you’ve selected a target, take a look back at your sprint questions. You usually can’t answer all those questions in one sprint, but one or more should line up with the target.

Main learning point: The first day of the sprint should really lay the groundwork for the rest of the sprint. Avoid the temptation to dive straight into solutions. Instead, spend the first day of the sprint to agree on a long-term goal and selecting a specific target to focus on!

Related links for further learning:

  1. http://www.nirandfar.com/2016/03/good-products-start-good-questions.html
  2. http://blog.invisionapp.com/inside-design-google-ventures/
  3. https://stfalcon.com/en/blog/post/how-to-quickly-check-startup-ideas-with-sprint

My product management toolkit (13): Continuous Discovery

marcabraham4 Comments

I know it’s a bit of a bugbear of mine; people coming up with assumptions and jumping straight into solutions to address their assumptions:

“I know what my customers want” 

“I know that I’m right”

“I’ve got umpteen years of experience in this sector, I know what people want”

“We’ve defined all customer requirements, we now just need to implement”

These are some of the comments that I hear quite regularly. Hearing comments like these have made me even more determined to constantly discover.

Discovery is all about about truly understand what your customers want (and why) or validating your assumptions, checking whether what you think is actually true. I learned that “Dual Track Scrum” is a great way to do discovery in an efficient and a continuous way (see some visual breakdowns in Fig. 1 and Fig. 2 below). Marty Cagan introduced Dual Track Scrum, citing Jeff Patton as his inspiration. I don’t tend to get too hung up on the word “scrum”, because one might not always be working in a Scrum type fashion. It could be Kanban, XP or any other iterative development approach that you might be using instead.

ux-in-a-dual-track-agile-world-11-638

Fig. 1 – Discovery feeding into Delivery – Taken from: http://www.slideshare.net/andreaneu/ux-in-a-dual-track-agile-world

Instead, I like talking about ‘Continuous Discovery’, stressing that ongoing learning drives product development. Rather than doing big chunks of customer research at the start and at the end of the product development lifecycle, I prefer to learn ‘early and often’. The key is to spend some time understanding the problem first, before coming up with ideas or solutions to implement. With a ‘dual track’ approach, you’re constantly discovering and validating customer needs which can then be fed into the delivery of working software.

The outputs of a discovery track can come in all kinds of shapes and sizes:

  • A set of user stories and acceptance criteria
  • Design assets or wireframes
  • A prototype of a varying degree of fidelity
  • Learnings about user issues with working software
  • Data from a live experiment (e.g. A/B testing)

I often get asked why and when to best to use this Continuous Discovery approach and I thought to quickly summarise these FAQs:

Question: “Why can’t I just go and build stuff, launch and see what happens?”

My answer: I’d be the last person to stop you from building things, measuring and learn. However, I strongly believe that a large part of ‘continuous discovery’ is about mitigating (product) risk. Instead of spending a couple of weeks or months building something before you get actual customer feedback, I’d rather get customer feedback ‘early and often’, based on an product or a feature that has been used by actual users.

Question: “With these discovery sprints, isn’t there a big risk of ‘analysis paralysis’?”

My answer: No. By time-boxing and fixing the scoping of each discovery cycle, you can make sure that you constantly validate your riskiest assumptions or investigate things that can then go straight into the next development sprint. Each discovery cycle should result in a tested set of customer needs, user stories and/or wireframes which will then be converted into working software the following sprint.

Question: “Aren’t’ we just going over old ground?”

My answer: From my experience, even if you have working software, by constantly testing it you’ll be able to fix bugs and develop a better product. It might seem tedious but I feel that this approach is a lot less risky compared to companies just doing a (soft) launch at the end of the development process and hoping for the best. Continuos discovery is not an alternative waterfall type approach,where you create additional stage gates and isolated process. In contrast, since development is still happening in tandem; you’re effectively discovering what needs to developing in the next iteration whilst people are building what you discovered in the previous discovery track.

SP8sqTc

Fig. 2 – Dual-Track Development – Taken from: https://confengine.com/agile-singapore-2016/schedule

Main learning point: Instead of gathering customer requirements on a one off basis, I strongly recommend doing this continuously. Having designated discovery tracks that feed into development cycles will help in discovering customer problems and needs ‘early and often.’ This helps you in making sure that you’re building the right product for the right customer whilst you’re designing and building it.

Related links for further learning:

  1. http://svpg.com/dual-track-scrum/
  2. http://www.cio.com/article/3075356/application-development/are-you-building-the-right-solution.html
  3. http://johnpeltier.com/blog/2015/07/12/dual-track-agile-better-products-faster/
  4. http://jpattonassociates.com/common-agile-isnt-for-startups/#more-1105
  5. https://www.quora.com/What-is-dual-track-scrum
  6. https://www.infoq.com/presentations/lean-product-discovery
  7. http://aaron.sanders.name/dual-track-scrum-brief/
  8. http://productwarrior.com/blog/2015/4/9/eliminate-waste-in-your-development-pipeline

My product management toolkit (9): playing devil’s advocate

marcabrahamLeave a comment

How often do you get agitated when someone starts challenging your product idea? What’s your typical reaction when people ask critical questions about your assumptions or an idea that you’ve come up with?

I have to admit that I’ve learned – and will continue to learn – to not take challenges or criticism personally. I now even go a step further and will either play the role of devil’s advocate role myself or will ask a team member or customer to take on this role. As uncomfortable as it can sometimes be, looking at the worst case scenarios or poking holes in a solution can really help in creating great products and avoiding critical mistakes.

Tool 9 – Playing devil’s advocate

2b347d70f2414406bbf8a8eeb3abd7ed_55465cfac70548ebb29cd3d638a15ff2_1_www_marquee_standard

Taken from: http://digg.com/2015/devils-advocate-literally

Why is it important to play devil’s advocate when developing or improving products? – As a product manager you can easily become wedded to your ideas or solutions. Especially as you get further down the product development cycle, there’s a serious risk of developing tunnel vision and becoming blind to any product or market risks. You can avoid this risk by inviting or assigning someone with the task of picking holes in your idea or assumption. This ‘someone’ can be another team member, a business stakeholder or a customer.

What are the benefits of being challenged? – I see three main benefits to creating a challenge where you’re constantly looking for (critical) feedback, always looking for things that could cause your product to fail:

  • Identifying and sizing risks early and often – Creating a culture where it’s ok to ask difficult questions or to learn through failures will help you identify and mitigate risks early on in the product lifecycle. This approach of teasing out risks will ultimately save your business a whole lot of precious time and effort, since you’re not waiting until the product has been launched to have difficult conversations.
  • Creating a more collaborative culture – If your colleagues understand what it is that we’re trying to achieve and why, having team-wide conversations about what is or could go wrong with a particular idea or product will become much easier. You’ll be surprised how creating such a culture will give others in the team a sense of ownership. Instead of just the product manager owning a problem and the team owning the solution, these boundaries will disappear as soon as people feel comfortable asking challenging questions.
  • Being on the front foot – I recently came across by a talk by Astro Teller, scientist and entrepreneur, in which he stressed the importance of doing a “pre-mortem” at the start of a project or product lifecycle. The goal of this pre-mortem session is to “predict failure”: identifying where things are likely to go wrong and to collectively assess this likelihood. I’ve added some more detail about what goes into a pre-mortem session in Fig. 1 below. “Asking the 5 Whys” is another simple technique you can use to proactively challenge an idea (see Fig. 2 below).

Are there any downsides to playing devil’s advocate? – Yes, ‘analysis paralysis’ and ‘death march’ are the most common risks with regard to being open and proactive about things that can go wrong:

  • Becoming risk adverse – I’ve seen instances where people take playing the devil’s advocate to the extreme. They end up spending a lot of time upfront to discuss all the risks involved or reasons not to build a product. As a result, ‘analysis paralysis’ arises and product managers becoming risk adverse. Time boxing the time spent on playing devil’s advocate helps overcome this issue.
  • Death march – “Trust” and “respect” are key words when it comes to talking about product solutions. What you want to avoid is creating a culture where people stop coming up with new ideas because they worry about their ideas being shot down at any opportunity. I believe this can be solved by adopting basic feedback skills. For example, if a person is looking to critique a particular idea, the onus is on her to provide constructive feedback, explaining the underlying feedback rationale and presenting options for solving the problems.

Main learning point: Getting internal and external feedback as early and often is a critical prerequisite for successful products or service. We can make this feedback more focused and valuable by actively encouraging people to play devil’s advocate. Even though this technique might not always be easy, it will help you identify and manage risks or negative impacts early on in the development and go-to-market process.

 

Fig. 1 – What to cover in a pre-mortem – Adapted from: http://singularityhub.com/2016/04/18/the-secrets-of-x-these-5-principles-will-help-your-company-make-moonshots-happen/

  • Kill product ideas early – Use a pre-mortem with your team to explore why a particular idea is likely to fail. Encourage people to try their hardest to prove that an idea is never going to work.
  • Explore the hardest parts of an idea first – We all know how easy it is to get excited about an idea and think/hope that a problem will be easy to solve. With the pre-mortem, however, team members will challenge each other on the complexities and risks of an idea. You’re thus effectively encouraging the team to kill ideas instead of committing to ideas that aren’t going to work.
  • What’s the negative impact? – Using techniques like impact mapping can help uncover any negative impacts that your idea might have on the overall customer experience, resources, market positioning or legal aspects. Yes, product managers need to be brave, but you’d rather identify any major product risks upfront and see if/how they can be mitigated.
  • Vote for ideas to be killed – The best way to make people feel comfortable about killing ideas early is by enabling them to vote or deprioritise bad ideas.
  • Ideas worth pursuing – As Astro Teller argues, the net benefit of a successful pre-mortem is that “the ideas that survive this process (the ideas you literally can’t kill) are the good ideas worth pursuing.”

Fig. 2 – A simple way of asking the 5 Whys to look closer at a problem or an idea – Taken from: https://en.wikipedia.org/wiki/5_Whys

  • The vehicle will not start. (the problem)
  1. Why? – The battery is dead. (first why)
  2. Why? – The alternator is not functioning. (second why)
  3. Why? – The alternator belt has broken. (third why)
  4. Why? – The alternator belt was well beyond its useful service life and not replaced. (fourth why)
  5. Why? – The vehicle was not maintained according to the recommended service schedule. (fifth why, a root cause)

Related links for further learning:

  1. http://www.riskology.co/pre-mortem-technique/
  2. https://hbr.org/2007/09/performing-a-project-premortem
  3. https://www.youtube.com/watch?v=mlVVlr0B0FA
  4. http://nasiji.com/astro-teller-predict-failures-before-beginning/
  5. http://www.astroteller.net/talks/entrepreneurship-thought-leadership-invited-talk
  6. http://www.huffingtonpost.com/peter-diamandis/secrets-of-x-formerly-goo_b_9714538.html
  7. https://en.wikipedia.org/wiki/5_Whys

No more features on product roadmaps – Have themes or goals instead!

marcabraham7 Comments

You might have read my one of my previous blog posts about the so-called goal oriented roadmap. I  prefer goal-oriented roadmaps over their more traditional counterparts. My problem is that ‘classic’ roadmaps contain a mix of features and timings, but don’t provide any context whatsoever (I’ve included an example in Fig. 1 below). I typically don’t include features on a roadmap and focus on user or business problems instead. As such, the roadmap becomes a tool for ‘working backwards’ – enabling product teams to explore solutions for given problems or desired results.

I recently learnt from Jared Spool and Bruce McCarthy about adding “themes” to product roadmaps. McCarthy told Spool about the concept of adding themes, and Spool became an instant fan. Like me, McCarthy isn’t a fan of having features on a roadmap. Instead, he suggests adding “themes” to the roadmap and this is why:

  1. Open to ‘options’ –  McCarthy believes that by having specific features on a roadmap, you run the risk of sending a product team down a certain avenue (and closing off any potential side streets). For example, if you were to just put “data dashboard” on a roadmap, chances are you’ll end up with a data dashboard. However, what would happen if you were to put “provide our customers with data to make key decisions” or “no data access” on the roadmap instead? By focusing solely on solution you run the risk of falling victim to what Josh Wexler calls solution sickness. Solution sickness is all about fixating on a solution and ignore any alternative ways of solving a problem.
  2. Customer focus – Jared Spool makes a great point when he says “When companies talk about features, they are saying, “Look at us. Look at what we can do.” He goes on to explain that “When companies talk about the problems of customers, they are saying, “Look at what you’re dealing with. Look at how we want to help.” It’s very easy to get fixated on features and forget about the underlying problems you’re looking to solve.
  3. Helping trade-off decisions – One of the things I love about both the goal-oriented and ‘theme’ approach to roadmapping is that it forces you to consider ‘why’ you want to develop certain products or services. What problem are we looking to solve and why? Why do we feel this problem is worth solving? Why should we prioritise this problem over others? Both the goal oriented and the theme roadmap approaches help make customers and their problems the core of everything you do as a product person. When I use the goal oriented roadmap, I always take out the “feature” layer purely because I don’t want us to be pinned down to one solution.
  4. “Marketing the story of solutions” – Which do you think would be an easier story to sell to customers? Option 1: “You can now use this real-time data dashboard which you can access via your content management system, enabling you to filter the data and extract reports” or Option 2: “You can use our data to decide on whether now is good time to sell your house?” … Easy, isn’t it!? As Jared Spool points out, the ‘theme’ approach makes it much easier for marketing teams to tell a story about a product or service: “Here are the problems we set out to solve and here’s how we solved them.”
  5. A more cohesive design – Design is another area which is positively impacted by a shift in focus from solutions to problems. From experience, I know how much easier it is to prioritise against a problem that you’re looking to solve, instead of trying to cram in a lot of features which you think might have an impact. As Spool puts it: ” Without a commitment to specific solutions, the team has flexibility.” As a result, product teams stand a better chance of creating simpler, well designed products.

Main learning point: I really encourage all product managers – the ones who aren’t doing so already – to think much more in terms of user problems instead of focusing on features. Not only will this help you in focusing your product efforts, I believe it will also make you much more customer centric.

 

Fig. 1 – Example of a traditional roadmap – Taken from: https://roadmunk.com/

project-roadmap

 

Fig. 2 – Goal oriented roadmap example – Taken from: http://www.romanpichler.com/blog/agile-product-roadmap/

SampleGOProductRoadmap_DanceGame

Related links for further learning:

  1. https://medium.com/@josh_wexler/beware-solution-sickness-producttank-nyc-talk-caffc23becfa
  2. https://medium.com/uie-brain-sparks/themes-a-small-change-to-product-roadmaps-with-large-effects-a9a9a496b800