Book review: “Autonomy”

Lawrence Burns is a veteran of the automative industry. Having worked his entire professional career in the car industry – in Detroit, the birthplace of modern car manufacturing no less – you might expect Burns to be apprehensive about ‘change’ and modern technology. The opposite couldn’t be more true of Burns, since he’s been an advocate for driverless cars for the past 15+ years, starting his foray into this field whilst at General Motors.

In his latest book, “Autonomy: The Quest to Build the Driverless Car – and How It Will Reshape Our World”, Burns and cowriter Christopher Shulgan paint a picture of driverless cars dominating our streets and roads, and having a positive impact on the environment and transportation as a whole. For those sceptics out there who dismiss driverless cars as science fiction, I recommend they read “Autonomy” and take note of the technology and societal developments Burns describes:

Getting started, the DARPA Challenge and Google’s “Project Chauffeur”:

The book starts off with the story of the “DARPA Challenge” in 2004 and how this helped shaped learning and development with respect to driverless cars. Burns gives the reader a good close-up of the experiences and learnings from one of the teams that took part in this challenge. At this first DARPA challenge, every vehicle that took part crashed, failed or caught fire, highlighting the early stage of driverless technology at the time.

Image taken from: https://www.wired.com/story/darpa-grand-urban-challenge-self-driving-car/

Driverless cars are the (near) future:

Bob Lutz, former executive of Ford, Chrysler and General Motors, wrote an essay last year titled “Kiss the good times goodbye”, in which he makes a clear statement about the future of the automotive industry: “The era of the human-driven automobile, its repair facilities, its dealerships, the media surrounding it – all will be gone in 20 years.” There’s no discussion that driverless cars are coming, especially that both car and technology giants are busy developing and testing. When I attended a presentation by Burns a few months agogo, he showed the audience  examples of both self driving cars and trucks:

Image taken from: http://www.autonews.com/article/20170316/MOBILITY/170319877/bmw-says-self-driving-car-to-be-level-5-capable-by-2021

Image taken from: https://newatlas.com/volvo-vera-self-driving-truck/56312/

In “Autonomy”, Burns brings Lutz’ predictions to life through the fictitious example of little Tommy and his family. In this example, Tommy steps into a driverless which has been programmed to take him to school in the morning. Tommy’s grandma will be picked up by a driverless two-person mobility pod to take her to a bridge tournament. Burns describes a world where car ownership will be a thing of the past; people using publicly available fleets of self driving cars instead.

Image taken from: https://www.thenational.ae/business/technology/autonomous-pods-the-future-of-city-driving-1.730283

Together with Chris Borroni-Bird, Burns has done extensive research into the potential impact of an electronic self driven car, looking at metrics such as “total expense per mile”, “cost savings per mile” and “estimated number of parts”. Borroni-Bird and Burns provide some compelling stats, especially when contrasted against conventional cars. Reading these stats helps to make the impact of driverless technology a lot more tangible, turning it from science fiction or future music into a realistic prospect.

Main learning point: “Autonomy” by Lawrence is an insightful book about a driverless future, written by a true connoisseur of the car industry and the evolution of driverless technology.

Related links for further learning:

  1. https://spectrum.ieee.org/cars-that-think/transportation/self-driving/auto-consultant-lawrence-burns-dishes-the-dirt-on-waymo
  2. https://www.youtube.com/watch?v=-pLM-2bxNMc
  3. https://www.youtube.com/watch?v=SJVKY1DtZ84
  4. https://www.forbes.com/sites/greggardner/2018/08/23/an-interview-with-self-driving-visionary-larry-burns-co-author-of-autonomy/
  5. http://www.autonews.com/article/20171105/INDUSTRY_REDESIGNED/171109944/industry-redesigned-bob-lutz
  6. https://lucidmotors.com/
  7. https://electrek.co/2017/01/02/lucid-motors-autonomous-tech-all-electric-sedan-mobileye/
  8. http://www.thedrive.com/opinion/9024/who-is-really-1-in-self-driving-cars-you-wouldnt-know-it-from-navigants-controversial-report
  9. https://news.stanford.edu/2017/05/22/stanford-scholars-researchers-discuss-key-ethical-questions-self-driving-cars-present/
  10. https://www.thenational.ae/business/technology/autonomous-pods-the-future-of-city-driving-1.730283
  11. https://www.wired.com/story/darpa-grand-urban-challenge-self-driving-car/
  12. https://spectrum.ieee.org/cars-that-think/transportation/self-driving/google-has-spent-over-11-billion-on-selfdriving-tech

Michael Margolis: “user research, quick and dirty” (1)

Why do I keep coming across businesses that struggle to engage with their (prospective) customers, to learn about their needs and behaviours? Too often for my liking, I hear comments like:

“Marc, we’re a startup, we don’t have the time and budget to do customer research!” 

“I’m not allowed to talk to customers.” 

“In my old place, we used to have a dedicated user research team and they’d just give me their research report on a platter, after them having spoken to users.”

It therefore felt quite timely when a colleague pointed me in the direction of Michael Margolis, UX Research Partner at Google Ventures.  Back in 2013, Margolis delivered a great Startup Lab workshop in which he covered the ins and outs of “User research, quick and dirty”. The recording of the 90 minute workshop is available on YouTube and you can find Margolis’ slides here (see also Fig. 1 below).

Fig. 1 – Michael Margolis’ Startup Lab workshop: “User Research, Quick ‘n’ Dirty” – Published on 26 February 2013 on https://youtu.be/WpzmOH0hrEM

I watched Margolis’ workshop in full and these are my main takeaways:

Seeing through users’ eyes

Margolis started off his session by talking about the importance of continuously learning about users, seeing things through their eyes. In a subsequent Medium post, Margolis writes that in his experience, startups will typically use UX research to achieve one of these objectives:

  1. Improve a process or worklflow
  2. Better understand customer shopping habits
  3. Evaluate concepts
  4. Test usability
  5. Refine a value proposition

Two types of user interviews

It’s great to hear Margolis making a distinction between two types of interviews:

  • Usability: A usability interview is all about learning whether users can actually use your product and achieve their goals with it. Can users do it? Can they understand it? Can they discover features?
  • Discovery: Discovery type user interviews tend to be more contextual, and delve more into the actual user. Who? Where? When? Why? How? All key questions to explore as part of discovery, as well as the user’s existing behaviours, goals, needs and problems.

Margolis then talks about combining the two interview types and highlight two sample questions to illustrate this combination:

“How do you do things now?”

“How do you think about these things?”

The distinction between “usability” and “discovery” isn’t just an artificial one. I love Margolis’ focus on objectives, acknowledging that objectives are likely to vary depending on the type of product, its position within the product lifecycle and the learnings that you’re looking to achieve. I’ve found – at my own peril – that it’s easy to jump straight into defining user tasks or an interview script, without thinking about your research objective and what Margolis calls “North Star questions” (see Fig. 2 below).

Fig. 2 – Michael Margolis’ 5 studies startups needs most- Taken from:  https://library.gv.com/field-guide-to-ux-research-for-startups-8569114c27fb – Published on 5 May 2018 

Margolis provides some very useful pointers about discovery and usability questions, which you can use to create a research plan and an interview guide:

Sample discovery questions – as suggested by Michael Margolis:

  • What are users’ behaviours, attitudes and expectations towards the product?
  • Who are the key user groups? What are their needs and behaviours?
  • What are the pros/cons of different designs? Why?
  • What are the pros/cons of competitor products?
  • How are people using existing/competitor products? What features are mots important and why?
  • What barriers hinder users from adopting <product>?

Sample usability questions – as suggested by Michael Margolis:

  • Can users discover feature X?
  • Are users able to successfully complete primary tasks? Why (not)?
  • Do users understand feature X? Why (not)?

In a similar vein, I believe it’s important to distinguish between problem and solution interviews. There’s a risk of your customer insights becoming muddled when you mix problem and solution interviews, especially if you alternate problem questions with solution questions.

In a problem interview, you want to find out 3 things:

  • Problem – What problem are you solving? For example, what are the common frustrations felt by your customers and why? How do their problems rank? Ask your customers to create a top 3 of their problems (see the problem interview script in Fig. 1 below).
  • Existing alternatives – What existing alternatives are out there and how does your customer perceive your competition and their differentiators? How do your customers solve their problems today?
  • Customer segments – Who has these problems and why? Is this a viable customer segment?

Fig. 3 –  Outline of a problem interview script – Taken from: Ash Maurya – “Running Lean”

In a solution interview, you want to find out 3 things:

  • Early adopters – Who has this problem and why? How do we identify and engage with early adopters? (see Fig. 3 below)
  • Solution – How will you solve their problems? What features do you need to build as part of your solution, why?
  • Pricing/Revenue – What is the pricing model for your product or service? Will customers pay for it, why?

Fig. 4 – Outline of a solution interview script – Taken from: Ash Maurya – “Running Lean”

Main learning point: In his Startup Lab workshop, Michal Margolis, drops a lot of very valuable tips on how to best keep customer research quick and simple, whilst still learning the things about your customer and/or product that you’re keen to learn. So much so that Michael Margolis’ tips warrant another blog post, which I’ll share soon!

Related links for further learning:

  1. https://library.gv.com/field-guide-to-ux-research-for-startups-8569114c27fb
  2. https://library.gv.com/user-research-quick-and-dirty-1fcfa54c91c4
  3. https://www.slideshare.net/LauraKlein1/shut-the-hell-up-other-tips-for-learning-from-users
  4. https://www.youtube.com/watch?v=WpzmOH0hrEM
  5. https://library.gv.com/tagged/design
  6. https://medium.com/@maa1/book-review-just-enough-research-2d714d447eda
  7. https://medium.com/@maa1/my-product-management-toolkit-23-customer-empathy-a1e66ff15012

Book review: Sprint (Part 4 – Day 3)

Once you’ve starting to think about possible solution – during Day 2 of the sprint – the next step is to take your huge pile of solutions and decide on which solution(s) to prototype. In the morning, you’ll review and critique the different solutions and select those solutions which you feel have the best change of meeting your long-term goal. In the afternoon, you’ll take the winning scenes from your ‘solution sketches’ and convert them into a storyboard. The goal behind this storyboard is to have a clear plan in place before you create a prototype to test with customers.

Decide

The main objective for the third day of your sprint is to decide on which solutions to prototype. In “Sprint”, Jake Knapp, John Zeratsky and Braden Kowitz suggest a number of techniques to optimise your decision-making process:

  1. Art museum: Put the solution sketches on the wall with masking tape.
  2. Heat map: Look at all the solutions in silence, and use dot stickers to mark interesting parts.
  3. Speed critique: Quickly discuss the highlights of each solution, and use sticky notes to capture big ideas (see Fig. 1 for a breakdown of how speed critique works).
  4. Straw poll: Each person chooses on solution, and votes for it with a dot sticker.
  5. Supervote: The Decider makes the final decision, with more stickers.

Fig. 1 – How speed critique works – Taken from “Sprint”, p. 136:

  1. Gather around a solution sketch.
  2. Set a time for three minutes.
  3. The Facilitator narrates the sketch. (“Here it looks like a customer is clicking to play a video, and then clicking over to the details page …”)
  4. The Facilitator calls out standout ideas that have clusters of stickers by them. (“Lots of dots by the animated video …”)
  5. The team calls out standout ideas that the Facilitator missed.
  6. The Scribe writes standout ideas on sticky notes and sticks them above the sketch. Give each idea a simple name, like “Animated Video” or “One-Step Signup.”
  7. Review concerns and questions.
  8. The creator of the sketch remains silent until the end. (“Creator, reveal your identity and tell us what we missed!”)
  9. The creator explains any missed ideas that the team failed to spot, and answers any questions.
  10. Move to the next sketch and repeat.

Rumble

A “Rumble” is a test whereby two conflicting ideas will be prototyped and tested with customers on the final day of the sprint. Instead of having to choose between two ideas early on, a Rumble allows your team to explore multiple options at once. If you have more than one winning solution, involve the whole team in a short discussion about whether to do a Rumble or to combine the winners into a single prototype. Knapp, Zeratsky and Kowitz suggest a good decision-making technique, “Note and Vote”, which you can use at any point throughout the sprint where you and your team need to make a decision (see Fig. 2).

Fig. 2 – Note and Vote – Taken from “Sprint”, p. 146:

  1. Give each team member a piece of paper and a pen.
  2. Everyone takes three minutes and quietly writes down ideas.
  3. Everyone takes two minutes to self-edit his or her list down to the best tow or three ideas.
  4. Write each person’s top ideas on the whiteboard. Ina  sprint with seven people, you’ll have roughly fifteen to twenty ideas in all.
  5. Everyone takes two minutes and quietly chooses his or her favourite idea from the whiteboard.
  6. Going around the room, each person calls out his or her favourite. For each “vote”, draw a dot next to the chosen idea on the whiteboard.
  7. The Decider makes the final decision. As always, she can choose to follow the votes or not.

Storyboard

Creating a storyboard is the final activity on the third day of the sprint. The goal here is to create a plan first before you start prototyping. You’ll take the winning sketches – see “Decide” above – and combine them into a single storyboard.

Fig. 3 – Example of a storyboard – Taken from: http://www.chadbeggs.com/storyboards.html

storyboards_02

From experience, creating a good storyboard will take a good couple of hours. What makes a ‘good’ storyboard? Knapp, Zeratsky and Kowitz list a good set of rules to help you and your team to fill out your storyboard:

  • Don’t write together – Your storyboard should include rough headlines and important phrases, but don’t try to perfect your writing as a group. Group copywriting is a recipe for bland, meandering junk, not to mention lots of wasted time.
  • Include just enough detail – Put enough detail in your storyboard so that nobody has to ask questions like “What happens next?” or “What goes where?” when they’re actually prototyping on the fourth day of the sprint.
  • The Decider decides – You won’t be able to fit in every good idea and still have a storyboard that makes sense. And you can’t spend all day arguing about what to include. The Decider can ask for advice or defer to experts for some parts – but don’t dissolve back into a democracy.
  • When in doubt, take risks – If a small fix is so good and low-risk that you’re already planning to build it next week, then seeing it in a prototype won’t teach you much. Skip those easy wins in favour of big, bold bets.
  • Keep the story fifteen minutes or less – Make sure the whole prototype can be tested in about fifteen minutes. Sticking to fifteen minutes will ensure that you focus on the most important solutions – and don’t bite off more than you can prototype. (A rule of thumb: Each storyboard frame equals about one minute in your test.)

Main learning point: The third day of your sprint is all about ending the day with a storyboard that you can use as a starting point for a prototype, that you and your team will be creating on the fourth day of the sprint.

Related links for further learning:

  1. https://uxmag.com/articles/why-we-need-storytellers-at-the-heart-of-product-development
  2. https://uxmag.com/articles/book-excerpt-the-user-experience-team-of-one
  3. http://www.chadbeggs.com/storyboards.html
  4. http://www.sarahdoody.com/3-ways-storytelling-can-improve-your-product-development-process/

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/

Priya Prakash explains about Design Principles at Mobile Academy

As part of the Mobile Academy curriculum, I recently attended a class by Priya Prakash on “design principles”. Priya is a very experienced designer and has founded Design for Change, a London-based urban experience design studio.

Priya started off the session by explaining that design principles describe the experience of core values of a product or a service. Design principles help in making decisions on your product. She referred to a great definition of design principles by Luke Wroblewski (see Fig. 1 below). The important part of Luke’s definition is that all decisions can be measured against design principles.

“Design is what you decide not to do” was one of the key points that Priya raised in this class. It’s all about doing less and simplifying things.  She talked about Spotify and Google Glass as good examples in this respect:

  1. Content first – Focus on the content, and remove any unnecessary user interface elements.
  2. Get familiar – Even though there is a clear distinction between a “lean forward” mode (Spotify desktop app) and “lean back” mode (Spotify mobile app), there’s a unified design language which has been executed consistently, irrespective of the device that you access Spotify from.
  3. Don’t get in the way – Google Glass is designed to be there when you need it and to be out of the way when you don’t. The goal is to offer engaging functionality that supplements the user’s life without taking away from it.
  4. Keep it relevant – Deliver information at the right place and time for each Google Glass user.

Priya then talked about motion user interface design principles:

  1. Personality – For example, the Pitchfork app has a magazine like feel. It’s about understanding what the content is and translating this into appropriate behaviours.
  2. Responsive – Priya talked about the Clear app as being very responsive, explaining how this app gracefully expands or contracts.
  3. Context – Motion should give context to the content on screen by detailing the physical state of those assets and the environment they reside in.
  4. Emotive – This principle is all about evoking a positive emotional response. This kind of response can be triggered by wide range of user interface elements, for example  smooth transition or a nice animation. Yelp‘s app is a good example in this regard.
  5. Orientation – Motion should help ease the user through the experience.  The “orientation” principle means that motion should establish the “physical space” of the app by the way objects come on and off the screen or into focus. The key is to get the flow of actions right, guiding the user on her journey and make sure she doesn’t feel lost or confused. Mobile apps like Yelp and Evernote do this pretty well in my opinion.
  6. Restraint – Keep it simple! Similar to the abovementioned “orientation” principle, it’s important not to bombard the user wity too much animation or confuse them with too many interactions to choose from. This is one of the reasons why I’m so a big fan of single purpose apps; I like the simplicity that they offer and the level of design restraint that they tend to apply.

Main learning point: I learned a lot from Priya Prakash’s class on design principles, particularly with respect to motion user interface design principles. Design principles can provide valuable guidance for the design of any software product or service and should therefore not be taken lightly. Thanks to Priya for a great class!

Fig. 1 – Definition of design principles by Luke Wroblewski – Taken from: http://www.lukew.com/ff/entry.asp?854

“Design principles are the guiding light for any software application. They define and communicate the key characteristics of the product to a wide variety of stakeholders including clients, colleagues, and team members.”

“Design principles articulate the fundamental goals that all decisions can be measured against and thereby keep the the pieces of a project moving toward an integrated whole.”

Fig. 2 – What makes a good design principle? – Taken from Priya’s lecture at the Mobile Academy on 14 October ’14:

  • Specific enough to help make a choice
  • Focuses the team – avoid being broad
  • Measurable against user need or product/business goal

Related links for further learning: 

  1. https://developers.google.com/glass/design/principles
  2. http://www.theguardian.com/business/2014/aug/03/inside-spotifys-redesign
  3. http://www.lukew.com/ff/entry.asp?854
  4. http://pitchfork.com/news/52898-introducing-pitchfork-weekly-our-new-app/
  5. http://www.beyondkinetic.com/motion-ui-design-principles/
  6. https://www.vitsoe.com/gb/about/good-design
  7. http://www.uie.com/articles/creating-design-principles/
  8. http://www.slideshare.net/goldengekko/mobile-apps-design-trends-2014

App review: Do

I guess we all know how frustrating it can be to have to sit in meetings that just feel like a waste of time or that could have been dealt with in 30 minutes (instead of 3 hours). I know that there are quite a few apps out there which help us to run more productive meetings, but I decided to focus on Do:

  1. How did this app come to my attention? – I got an alert from Product Hunt about Tools for Product Managers, promising me a list of “the tools the pros use”. Do was only ranked 10th on this list, but I guess it was this comment from one of the Product Hunt voters, that intrigued me the most: “I was a Yammer PM. Do.com is the meetings platform I wished I had.” Especially given that it came from a guy who used to be at Yammer – who are all about collaboration within the enterprise – this comment made me want to find out more about the product.
  2. My quick summary of the app (before using it)  Do helps you to have more productive meetings; I therefore expected a tool which helps its users to make their meetings as efficient as possible. The tool doesn’t yet seem to be available on iOS or Android, only on PC.
  3. Getting started, what’s the sign-up process like?  I have to sign up to use Do. At present, Do only seems to support Google users; all non Google users will be notified as soon as they will be able to sign up (see Fig. 1 below). Once I’ve selected my Google account, I get presented with a permissions screen (see Fig. 2 below). I click “Accept” and my personal dashboard appears. All fairly straightforward.
  4. How does the app explain itself in the first minute? – The default page of my dashboard shows a simple timeline with meetings on the relevant dates and times (see an example in Fig. 3 below). To be honest, I felt a bit underwhelmed at first , thinking “is this it!?”. However, the subsequent overlay which consisted of six ‘how to’ screens was quite useful, explaining in a simple but effective way how to best get started on Do (see Fig. 4 below).
  5. How easy to use was the app? – Using the tool felt very intuitive and easy. The layout of the dashboard is clear and easy to understand. Adding a new meeting to the dashboard felt no different to doing the same thing in Google or Outlook (see Fig. 5 below).
  6. How did I feel while exploring the app? – Like I mentioned above, exploring Do felt incredibly easy and intuitive. The signposting used in the tool is self-explanatory and the navigation options have been kept to a minimum. A quick click-through on an individual agenda item highlighted a key purpose of Do; the ability to create and share a meeting outline, making it easy to collaborate around meeting goals and agenda items (see Fig. 6 below).
  7. Did the app deliver on my expectations? – Yes, it did. I felt a bit underwhelmed at first, expecting Do to provide more, ‘less obvious’ features. However, whilst playing with the application, I discovered features like “Invite” and “Takeaways”, which I believe are missing from most standard diary / meeting applications.
  8. How long did I spend using the app?  A few days to start with, but I expect to be using it a lot more in the future!
  9. How does this app compare to similar apps? – I had a quick look at MeetingHero which serves a similar customer proposition to Do. At a first glance, MeetingHero seems a bit less advanced and intuitive in comparison to Do. MeetingHero is, however, available as an app on iOS which means that the app can be used on the go.

Main learning point: Do is a straightforward and easy to use meeting app. I like its interface and its key features; the app makes collaborating around meetings very easy. It will be interesting to see how Do will perform in already crowded marketplace, with apps and systems that enable similar things. I’m now curious to see what the mobile version of the application will look like!

Fig. 1 – Screenshot of Do’s sign-up screen

Do 1

 

Fig. 2 – Screenshot of Do’s permission screen

 

Screen Shot 2014-09-30 at 05.09.57

Fig. 3 – Screenshot of sample meeting in my meeting calendar in Do

Screen Shot 2014-10-05 at 08.41.29

 

 Fig. 4 – Screenshot of one of the introductory ‘How to’ screens on Do

Screen Shot 2014-09-30 at 05.22.54

 

Fig. 5 – Screenshot of functionality in Do to create a meeting 

Screen Shot 2014-09-30 at 05.36.59

 

Fig. 6 – The ability  to share a meeting goal and agenda items

Screen Shot 2014-10-04 at 13.23.52

 

Twitch and its appeal for Google and Microsoft

The other day, I heard about the rumoured takeover of Twitch by Google for the handsome amount of $1 billion. I have to be honest; up until that point I had never heard about Twitch. Reason enough to look into Twitch and a possible ratio for Google willing to spend such a large amount of cash on this startup:

  1. What is Twitch? – Twitch is a video streaming platform and a community for gamers. Geekwire describes Twitch as “the ESPN of the video game industry” and says Twitch is a leader in that space. Twitch has over 45 million monthly users and about 1 million members who upload videos each month. In a relatively short space of time (Twitch was launched in June 2011), Twitch has successfully created an online streaming platform for video games.
  2. Who use Twitch? – I’m not an avid video gamer myself, but browsing the Twitch website tells me that are in effect two main user roles, which are closely intertwined: game players and broadcasters. Clearly, you can be both and I’m sure that a lot of Twitch members fulfil both roles. One can play games on Twitch channels like Counter-Strike: Global Offensive or World of Tanks or one can create their own pages from which you can broadcast games. A great example of Twitch’s success in engaging its community around a game is TwitchPlaysPokemon which has had over 78,000 people playing a game that turns chat comments into controller inputs, parsing hundreds of thousands of ups, downs, and starts and translating them into in-game movements.
  3. Why is Twitch such an interesting acquisition target? – Twitch is reported to have snubbed Microsoft’s takeover offer but is rumoured to have fallen for Google. This raises the question as to what makes Twitch such an interesting takeover target? I think that the answer can be split into two main factors. Firstly, scale. Twitch has a rapidly growing and very engaged user community who all share a passion for (video) gaming. Secondly, live broadcasting. Going back to the example of TwitchPlaysPokemon, Twitch streams games that get people excited and gets them participating in real-time. This simultaneous element is something that for instance YouTube is lacking. YouTube is great for on-demand video content, but (currently) less so for live event coverage or participation. The combination of both factors (as well as a very rich vein of user generated content and data) makes Twitch an extremely interesting target indeed.

Main learning point: Recently there have been some major takeover deals in the digital industry – think Instagram, WhatsApp and Beats – but the rumoured acquisition of Twitch by Google is interesting for a number of reasons. If I have to highlight one key reason, then synergy is the main aspect that makes this potential takeover sound like a very exciting one. How will Google potentially integrate YouTube and Twitch or at least find a way to combine both platforms? Will the acquisition of Twitch help YouTube in cracking the real-time broadcast element of its offering? Lets wait and see if the deal actually gets done in the first place, but if it does then I will definitely keep an eye out for any future developments involving Google, YouTube and Twitch.

Related links for further learning:

  1. http://www.fool.com/investing/general/2014/05/28/why-youtube-buying-twitch-for-1-billion.aspx
  2. http://www.geekwire.com/2014/microsofts-xbox-shot-potential-twitch-buyer-matters/
  3. http://variety.com/2014/digital/news/youtube-to-acquire-videogame-streaming-service-twitch-for-1-billion-sources-1201185204/
  4. http://techcrunch.com/2014/05/27/tc-cribs-tours-twitch-tv-gaming-office-headquarters/
  5. http://thenextweb.com/insider/2014/05/29/twitch-now-lets-filter-counter-strike-global-offensive-game-streams-map-skill-level/
  6. http://thenextweb.com/google/2014/05/19/google-reportedly-wants-buy-video-streaming-service-twitch-1b-deal-boost-youtube/
  7. http://variety.com/2014/digital/news/why-google-wants-to-hitch-twitch-and-youtube-1201188093/
  8. http://www.theverge.com/2014/5/20/5734108/why-twitch-could-be-the-best-billion-google-ever-spends
  9. http://guardianlv.com/2014/02/twitch-live-broadcast-to-be-included-in-xbox-one/

Twitch