RSS

Monthly Archives: August 2016

Book review: Sprint (Part 1 – Setting the stage)

I personally find it very encouraging to see that more and more companies go down the route of experimentation and continuous discovery. Businesses are starting to realise that committing to a single solution upfront and implementing it in the hope that it will be successful can be a very risky strategy. “Sprint – How To Solve Big Problems and Test New Ideas in Just Five Days” builds on this change by introducing the concept of a 5-day sprint in which to identify problems, explore possible solutions AND get feedback from real customers.

Jake Knapp and two of his colleagues at Google Ventures, John Zeratsky and Braden Kowitz, have successfully applied ‘sprints’ for a wide range of companies, helping the likes of Pocket and Blue Bottle to tackle difficult problems in just five days. This is how the five days are broken down:

  • Monday (day 1) – ‘Start at the end’; agree to a long-term goal and pick a problem to solve during the sprint
  • Tuesday (day 2)  Review and improve existing ideas and sketch possible solutions
  • Wednesday (day 3) – Select a solution to focus on and create a storyboard
  • Thursday (day 4) – Build a prototype, a realistic ‘facade’
  • Friday (day 5) – Learn through customer interviews

Sprint 1

Fig. 1 – Steven Nguyen “Reflecting on our first design sprint” – Taken from: https://sprintstories.com/reflecting-on-our-first-design-sprint-2d58519eefad#.ej6ivw4ma

The “Sprint” book contains a wealth of great techniques to utilise as part of a sprint. I want to do it justice and will probably devote a couple of posts to this great book. Before delving into each of the days of the sprint, let’s start by looking at ‘setting the stage’ before kicking off the sprint. It’s important to have the right challenge and the right team before you begin a sprint:

  • Challenge – As readers of my posts might know; I’m quite obsessed about understanding the problem(s) worth solving before exploring solutions. I therefore believe that picking the right problem or challenge to solve is absolutely critical to a successful sprint. Knapp, Zeratsky and Kowitz suggest three challenging situations where sprints can help: high stakes, tight deadlines or when you’re simply stuck.
  • Team – The key thing when assembling a sprint team is to get a ‘Decider’ in the team; someone who’s in a position to make important decisions. This can be the CEO or another important stakeholder. I like how the book provides a number of arguments one can use when a Decider is reluctant to get involved in the sprint (see Fig. 2 below). You should end up with a well balanced team, made up of people who can implement as well as subject matter experts (see Fig. 3 below).

On top of picking a team, it’s also important to have a designated facilitator who can manage time, conversations, and the overall process. Naturally, this can be someone from within your company or someone external. For example, I know lots of digital agencies that facilitate sprints as part of a piece of work for their clients. As much this is beneficial to the client, this also helps the agency by creating a shared and robust understanding of what’s going to be built and why.

Fig. 2 – Get a Decider (or two) involved – Taken from: “Sprint”, pp. 31-32

  • Rapid progress – Emphasise the amount of progress you’ll make in your sprint: In just one week, you’ll have a realistic prototype.
  • It’s an experiment – Consider your first sprint an experiment. When it’s over, the Decider can help evaluate how effective it was.
  • Explain the tradeoffs – Show the Decider a list of big meetings and work items you and your team will miss during the sprint week.
  • It’s about focus – Be honest about your motivations. If the quality of your work is suffering because your team’s regular work schedule is too scattered, say so. Tell the Decider that instead of doing an okay job on everything, you’ll do an excellent job on one thing.

Fig. 3 – Recruit a team of seven (or fewer) – Taken from: “Sprint”, pp. 34-35

  1. Decider – Examples: CEO, founder, product manager, head of design
  2. Finance expert – Examples: CEO, CFO, business development manager
  3. Marketing expert – Examples: CMO, marketer, PR, community manager
  4. Customer expert – Examples: researcher, sales, customer support
  5. Tech/logistics expert – Examples: CTO, engineer
  6. Design expert  Examples: designer, product manager

Main learning point: I recommend everyone doing a ‘sprint’ before committing to a specific solution. “Sprint” is a great book, with a lot of helpful guideance as to how to best solve big problems in five days. I’d argue that some of the techniques to use as part of sprint shouldn’t be constrained to a 5-day period or at the start of a piece work; I’ll outline in the coming posts how some of the sprint exercises can be used on a continuous basis.

 

Sprint 2

 

 

Related links for further learning:

  1. http://www.gv.com/sprint/
  2. https://sprintstories.com/
 

Tags: , , , , ,

My product management toolkit (13): Continuous Discovery

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
 
2 Comments

Posted by on August 20, 2016 in Agile, Product Management

 

Tags: , , ,

Voice-enabled security and payments

I know I’m slightly late to the game when it comes to voice recognition technology, but I was intrigued when I came across a mobile banking app by Dutch bank ING, which they launched about a year ago. This app uses a voice enabled security and payments system, which makes it possible for its clients to check their balance or make mobile payments using their voice. In order to log in, users will have to say a short phrase which the banking app then matches to a sound file stored on the user’s phone.

The underlying claim here is that the shape of a user’s vocal cavities and the way a user moves her mouth means that speech can be more unique than a fingerprint. Nuance, a US based biometrics company, has developed technology that analyses a user’s voice “for hundreds of unique characteristics that are then compared to the voiceprint on file.”

 

nuance_inge2-600x381

Instead of having to remember 15,000 different passwords or related security questions – you should be able to tell my frustration with existing security measures here – Nuance aims to do away with all this by matching the user’s voice to a stored voiceprint. This can be either passively, whereby the user can say anything to enable the matching or actively, whereby the user is asked to recite a specific passphrase. As a result, authentication should become a lot easier and less stressful for the user.

From the perspective of a bank like ING or any other company, voice-based security mitigates the risks inherent in knowledge-based security. Four-digit PINs or event digital fingerprints can be easily compromised, for example when a person is attacked. Passwords and security questions can be successfully answered with simple web searches of the account holder.

In contrast, it’s much harder to compromise voice biometrics. A voiceprint is a hashed string of numbers and characters, which means that it’s pretty meaningless to a fraudster. Even more so, each time a hacker tries to speak with a call centre or a mobile app, their own voiceprint will be left behind which can then be used to proactively keep them out of the system.

Thinking of mobile payment giants like WeChat (see Fig. 1) and M-Pesa (see Fig. 2) and the rapid raise of in-app payments, I can see voice-based see voice based technology taking great a great flight over the coming years.

wechat payments

 

Fig. 1 – WeChat screenshot – Taken from: http://www.digitalstrategyconsulting.com/intelligence/2014/08/wechat_adds_virtual_payments_to_messaging_app.php

 

how-to-get-started-with-m-pesa_9c15aaefd2e1bf2b764cf7b295ed365d

Fig. 2 – “How to get started with M-Pesa” – Taken from: https://www.vodacom.co.tz/mpesa/consumers/getting_started

Main learning point: I know that voice recognition isn’t yet where it needs to be in certain cases, but I can see how voice-enabled security and payments can provide a secure and seamless user experience, especially compared to issues related to the current knowledge based approach to passwords and security.

Related links for further learning:

  1. http://news.sky.com/story/make-mobile-payments-using-your-voice-10351022
  2. http://www.nuance.com/for-business/customer-service-solutions/voice-biometrics/index.htm
  3. http://www.techweekeurope.co.uk/mobility/mobile-apps/ing-netherlands-voice-password-nuance-173717
  4. http://www.cnet.com/news/google-wants-to-help-you-manage-your-passwords/
  5. http://www.ing.com/Newsroom/All-news/NW/Do-you-want-to-transfer-money-Just-say-it-out-loud.htm
  6. https://en.wikipedia.org/wiki/Interactive_voice_response
  7. https://techcrunch.com/2016/03/17/messaging-app-wechat-is-becoming-a-mobile-payment-giant-in-china/
 
Leave a comment

Posted by on August 7, 2016 in FinTech, Mobile, Technology

 

Tags: , , , ,