Seek’s Rob Scherer (Lead UX, Hirer products) and Rob Alford (Product manager, New products) came to talk to us about their use of Google Venture design sprints.

They were looking to come up with a completely new product idea and wanted to challenge themselves & the organisation. The guys did a great job of explaining the process without telling us what the market or product is – they are currently building the product & we can look forward to a very exciting launch I am sure.

Thirsty work at tonight’s @product_anon meetup. Thanks @moondogbrewing for the cool ales. More awesome #lifeattw pic.twitter.com/buUbGoP0Ur

— Nic Smythe (@NicSmythe) February 18, 2016

Before jumping into the design sprint, they worked with the person who would facilitate the session and tweaked the Google process to suit them. One of the main reasons for trying this approach was to ensure coverage from multiple functions of the business with an approach that forces (encourages!) collaboration and allows everyone to contribute. People from various departments are locked in a room for a week and aren’t allowed to leave…. (well, maybe not that strict! 🙂 )

As Google describes it: “We shortcut the usual endless-debate cycle and compress months of time into a single week. Instead of waiting to launch a minimal product to understand if an idea is any good, teams get great data from a prototype. The sprint gives these companies a superpower. The ability to build and test nearly any idea in just 40 hours.“

So what did Seek do differently to the Google approach:

Seek wanted to use the sprint methodology but were keen to make a few modifications to incorporate their own experiences to the process.

The Team

Google recommends 4-8 people for design sprint. Seek set up a bigger team of 12 people which allowed them to have a broad representation of the areas (development, marketing, strategy, BA, etc) needed to explore this space. While a senior person was in the room on the first day to help set the stage… that’s the only day! Having no senior team members helped do away with group think as no one was waiting for the senior person in the room to comment. They broke the 12 down into smaller groups of 3 for the sketching.

Time & Steps

The Google approach, takes a team of 4-8 people and spend one day for each of these steps:

Unpack -> Sketch -> Decide -> Prototype -> Test.

They also decided to add a few more steps to bring it to 7 days:

Unpack -> Build Empathy -> Sketch + test -> Sketch + test -> Decide -> Prototype -> Test.

Seek added ‘Build Empathy’ as a request from the UX team. The product guys weren’t so sure it would be useful, they were a little skeptical before doing it, but after trying it they were converted. With such a large group consisting of some people who were new to this type of work, having a day spent on empathy helped to ensure everyone’s mindset was in the right place for thinking about the customer. Seek also added more time to the Sketching section. They wanted to be able to sketch in the morning and then test those ideas in front of customers that afternoon. By doing this 2 days in a row, they had a lot of items validated before getting into the Decision day and presenting to the execs. They feel having the extra time to sketch/test worked really well for them.

Pre-planning & getting outside help

Before the design sprint even started they did a few things to help organise:

• Booked a dedicated space where they could keep the entire week’s sketches on the wall. They ended up having so much they took over the wall outside the meeting room. Seeing all the work they created over the week was very motivating to the team.
• Booked the people they’d be showing their sketches too (assisted by their usual research folks)
• Booked the meeting where they’d present to stakeholders
• Organised an external facilitator
• Organised homework for the team (see below for details)

A practical thing todo b4 you start. learn to draw exercise #prodanon everyone’s sketches look alike to customers https://t.co/lBLEevVZPf — product anonymous (@product_anon) February 18, 2016

What is involved in doing the design sprint?

There is a tonne to do to get ready for the sprint and if you look over the resources you will see that these are just a couple of tips to be aware of where to put emphasis and not skip!

1. Homework – Before the design sprint started, each member of team had to do their homework. Each person was given a competitor to research and everyone was asked to think about something that inspired them. At the start of the sprint they needed to talk for 2 minutes on each piece of their homework. NO POWERPOINT! The competitor research was kept intentionally light.. what they liked, disliked, etc. Just insight, observation and sharing with everyone else. This was a great technique for divide and conquer. The inspiration step was also a great tool for encouraging people to remain open-minded and positive about what they could do, instead of possibly limiting themselves to iterating only on what was out there already.
2. Learn to draw exercise – this was an amazing insight from the evening. Everyone was “taught” how to draw including the UX’ers. What this actually meant was that everyone was shown how to draw in a consistent manner so that ideas could be judged equally, not on the skill of the sketcher. Vedran has written up the details on Medium but bascially: use a thin liner pen to draw the outline then a sharpie to accentuate any aspects, a yellow highlighter to draw attention and one grey pen to indicate background/what to ignore. From here, when ideas from different people were combined, the customer could not tell the difference between the sketches and much time was saved by not having to redraw.
3. Everyone facilitates – to ensure inclusion everyone had a go at facilitating as unseasoned researchers will tend to present more than facilitate but for best results, this should be seen as facilitating user research rather than presenting designs to users.
4. Everyone takes notes – the intensity of the time-boxing might assume everyone pays attention but everyone was asked to take notes to avoid drifting off, but to ensure people remained engaged. It also helped with adding insights as people took things down and then had to repeat back what they had heard.
5. Guerilla testing – go to users unannounced and then try out your idea and you will get some very different responses. Rob & Rob noted the big difference in commentary you’ll receive between bringing customers into your office vs going to their environment where they feel comfortable. You’ll get more critical & real feedback when you are in their environment (plus they want to help you solve the problem & will give you ideas).

Key ingredients to success

1. Having time constraints – This was the most important factor for them & the faciliator was great in moving them along. Enforcing the time constraints meant they stayed focused, had something to show customers and were ready to present to the execs.
2. Right people – this means the right representation from the organisation for the area you looking to be innovative in but also avoiding any senior execs that might inadvertently provide bias too early.
3. Keep it visual – have everything on the wall where all can see it, communicate with images, drawing instead of talking.
4. Use an external facilitator – keeps things neutral, allows the entire team to contribute to the process instead of worrying about the process, can tell people to shut up and get working, which again might be a bit hard for one of the team.

Results (& Would they do it again?)

Yes, Seek have tried the methodology again since they got such a great result the 1st time. The team got a business case up in just a few weeks after the sprint, and the approval process was smoother due to the excitement the sprint had created. The team have been building the product since.

Rob A wasn’t convinced you could use it for every project, partly because it remains hard to convince an organisation to give up people for a week and partly because not every product needs such a methodology. On the other hand, participants of the sprint have gone on to use it in their area as they got so much out it. Aspects of the sessions have also been cherry-picked out as proving to be really helpful tools – such as the drawing component and have been applied in isolation.

It was great to get to hear from an organisation that has used the methodology with such success but also shared with honesty the tough aspects of running it. The intensity is clearly not for the faint-hearted and may well be a stronger reason for not re-using more frequently. As the team that were involved in the sprint went back to their day jobs or moved on to build the prototype into product their focus has also shifted for now. However, any company looking to break themselves out of their norms and product innovation from within should consider using this approach.

Further Resources:

Thanks again to ThoughtWorks for hosting + pizza & to Moondog Brewing for providing such tasty beverages.

RSVP for the next session in March as we talk more Google topics (API product management & being a product manager at Google)!

A great @product_anon Meetup at ThoughtWorks with @UXrob & Rob Alford from Seek on “using Google design sprints to drive innovation!”#UX

— Pasquale Stella (@Pasquale_Stella) February 18, 2016

Brilliant Q&A finishing the discussion tonight. TY to @SEEK_Geek @uxRob @robmalford @thoughtworks @NicSmythe @product_anon for your efforts. — Daniel Kinal (@dktpm) February 18, 2016

We hope you can join us on Thursday March 17th when Elena Kelareva, Product Manager at Google, talks with us about product managing APIs and product management at Google. RSVP now.

From the API perspective, the session will help you evaluate if an API would benefit your product by examining the potential benefits – like driving adoption, enabling niche use cases and opening up new revenue streams. Elena will also cover product strategy for your API, give a high-level overview of API design considerations, and present several issues to watch out for, such as differences between web and native mobile APIs, dealing with authentication and abuse, and what to do if your API ends up being too popular or not popular enough.

Elena will use examples from the Google Maps APIs as well as several well known APIs for other products.

And because there’s always questions on how Google does product management, Elena will also share her experiences.

Elena Kelareva is the Product Manager for the Google Maps Web APIs, including the JavaScript Maps API, used by over 2 million websites. She has a PhD in Computer Science from the Australian National University, and has previously worked as a Software Engineer at OMC International, building software that improves safety and prevents ship groundings at some of the world’s largest cargo ports.

Thanks to Envato for hosting!!

Our October event was all about transforming and optimising experiences for our users. – and both talks also included a healthy dose of tips for communicating value and change to your organisations.

We had two great speakers to delve into this topic – Kirsten Mann, Director for Global Design & Experience at Aconex and Leisa Reichelt, Head of Service Design and User Research at the Digital Transformation Office. Leisa brought quite a lot of insight having spent a number of years with the UK Government at the Government Digital Service (GOV.UK) and is now here to help the Australian government similarly improve their sites.

Kirsten started the evening telling us how Aconex brought down business costs by building a great support site.

It all started with the data – 4000 abandoned calls each month! The UX team thought this would be an easy thing to fix which could show measurable ROI – not always an easy relationship to draw. Aconex spends a lot of time & money on face-to-face training and travel so the UX team developed a vision statement to get rid of the cost heavy training approach …if they could provide a end-to-end online support system.

The team tried different ideas & prototypes – including some with aussie humour which didn’t translate across all cultures. 😉 After trial & error they came up with a new version of the support & training site. They saw a reduced cost as the need for F2F training was dramatically reduced.

The Aconex UX team had a great win by showing the organisation it could have real ROI impact. Being able to show this & have a win like this early will smooth the road for future plans – and save costs.

Part of the UX success at Aconex goes back to where UX fits into the organisational structure. Kirsten used a great metaphor of the 3 legged chair – you lose a leg and things will fall over! These legs consist of product management, tech and UX.

Our other special guest for the evening, Leisa Reichelt, has recently returned to Australia after a long time in the UK working at Government Digital Service (GOV.UK). Her focus is to transform public services with user centred service design. Why? Because in any 4 week period more than 1 in 8 Aussies, over 14, will use a government website. And 55% hit problems completing what they came to do.

[pullquote]I’m trying to stop people from crying[/pullquote]

Leisa took us though 4 learnings for user design at a gov’t organisation but the 4 are great for product managers as well.

1. show don’t tell
2. ask for less, simplify
3. change the language
4. plan to do more comms

show don’t tell

The show don’t tell principle is rather brilliant. In the product design world we talk ad nauseam about prototypes but what Leisa kindly reminded us about is the meetings we have telling people stuff are such a waste of time. We could be showing them something and having a discussion about what’s next instead of throwing out the “we’ve done that before” types of blockers.

Ask for less and simplify

This is a clever organisational navigation tip. We often despair when we cannot get the 1M we need for the whole project or the 3 resources we absolutely need to do all the projects. That’s when we give up and get nothing.

Why not ask for (& receive!) 20K, do something and then ask for more?!? Ask for 1 resource (or half a one) & use them brilliantly. Once you have something to show as a result of that resource, THEN ask for more.

Put a number in the request – don’t ask for lots of people or money as again this tends to leads to a no answer.

The approach of being specific with a figure led to some very clear guidelines on ensuring your purpose states what you are doing with measurable details. so you can show you are doing, but also so it is very clear how to get started!, how to keep going and prove you have used the resources you asked for.

[pullquote]Language is the medium through which culture is enacted – Gill Ereaut[/pullquote]

Change the language

This was an indulgently awesome moment as it is something I have been talking about at my companies for awhile now and appreciated Leisa being so forthright on the subject…

Any product manager will recognise this situation: that annoying moment when the nickname for a product suddenly becomes the language of the company & when you finally “announce” the real product name it is too late since it will forever be known as the nickname. < SIGH >

Leisa’s point is that language permeates even deeper than that. Her examples touched on the difference between calling yourself UX or UCD & then further on trying to put a nice interface over really terrible policy. If you want to get a different outcome you need to change the language.

Plan to do more comms

One cannot forget the need to communicate, communicate, communicate. When you think you said it enough, say it again!

You are not finished communicating until you are being told the story back to you as if it is fact. Make sure your message is clear (is it clear YET?) 🙂

She closed out the section stating that there isn’t any point doing the work if you aren’t going to share it.

So much wisdom from both these ladies on this wonderful night!!

Thanks to Aconex for their once again fantabulous hosting. A special thanks to Kirsten for pulling it all together! And awesome coordination/promotion with UX Melbourne and the UX Design Group of Melbourne! Let’s do it again guys!

Our last event for the year is on the 26th of November so please join us to reflect on the year that was, share ideas for next year and just mingle and network. No formal talks this session, just conversation, and a drink to wish Product Anonymous happy 5th birthday.