Walking the Line: The Line of Product Development - Paul Dawson, Flux

flux[x] @fluxxstudios @poleydee

Walking the line: The Role of Product

Development

Paul Dawson Partner, Experience & Innovation, Fluxx


The boring cred’s bit


A product & service innovation company

Se#ng Strategy & Vision

Developing & valida5ng products

Innova5on prac5ces & long term change


Ideal outcomes from this session?

Digital UX

Product design

Product development.

How to get better briefs that allow you to explore interesting opportunities and less dispute with the people who are ‘leading’ it

How to get closer to the product you had envisioned, and create greater harmony with the team tasked with making it great

“wtf ?”


There are two types of organisation in the world


Develop, design and sell products


Behave like they are a product company

Don't behave like a product company


‘Product’ is what is on the shop floor ‘Product’ is what we do


New Product Development (NPD)

q Strategy q  Ideas and insight q R&D Concepts q Developed & Validated Concepts

(Desirability, Viability, Feasibility) q Partnerships and organisation q Design & Build q Operate


The ‘Non Product’ Approach



Research

Business Case

Investment decision




Opinions, guesswork

and specula5on

The ‘Non Product’ Approach


Fortunately, most digital projects I’ve worked on start here:


But then they go one of two ways: Exci5ng, interes5ng, innova5ve.

Empowered, crea5ve, inspired

Detailed, monotonous, not thinking for myself

Demo5vated, dis-‐spirited, ‘done to’

What if…

Wireframes

An explora5on of why What new opportuni5es there might be within it New ideas, ‘blue sky’ thinking,…

Well, they seem to have made up their minds, we’ll just get on and be the wireframe monkeys shall we?


What if companies who know they are product companies did not behave like product

companies?


An imaginary new product “A new range of luggage specifically for the family”

The budget is set

The board is all behind it


Stage 1: Research

When product companies don’t behave like product companies


Stage 2: Envisioning

When product companies don’t behave like product companies


We could pre-load them with things people need


We could do niche products for specialist audiences


Hey, what if the suitcase became a mode of transport?!

Hey, what if the suitcase actually became the holiday?


But then…

“Product Owner”

But suddenly…

The more radical thinking simply gets dropped as it can’t be validated

Ideas may be good, they might not. Nobody is in a posi5on to judge before 5me starts running out.

“We’ve got a whole stack of basics to do first”


Agile approaches in non-product thinking companies…

Things we know we can do

Things we know our customers value

The unproven ideas domain


Stage 3: New ideas get pushed to the back and we focus in on the basics, having no time, resource or remit to progress our

half-formed ideas, no matter how brilliant they were…


but…

We have bright people, all eager to unleash their creative juices and we lost them quite

early on…


The Line

Exci5ng, interes5ng, innova5ve.

Empowered, crea5ve, inspiring



Anything is possible

I have a very 5ght, prescrip5ve brief


We might have had the ‘right ideas’


but we haven’t been able to ‘make those ideas right’


Now design something magnificent

What we needed was an inspiring brief with real possibilities

“Design a suitcase that children and parents will love.

We know that hassled parents and kids will love a ride-‐on case. We can save 5red parent arms and 5red toddler legs and

make travel fun.”

Research & Insight:

A clear product proposi8on:


And that’s what product development is


Product Development is pure UCD

But it doesn’t design interfaces, and it’s not concerned with usability or ergonomics

desirable feasible

viable


Product Development’s Goals

1.  To flesh out and validate product and service propositions

Desirable: Customers will find value in it Feasible: We can make it work Viable: It can be an economic success

2.  Prove that this is the right thing to do, kill it early, or learn enough to turn it into the right thing to do

3.  To arm a design and build team with all they need to get the product designed and built in the right way


But what many product development teams miss is… That once they’ve ‘developed’ the idea into a

product, the customer experience still has to be designed

(because generally, they’re a bit crap at doing that bit!)


I’ve been on both sides

Digital UX Product development.


“The CEO had a designer mock something up”

“We’ve had a product design consultancy working on it”

“We’ve developed a new brand, and the branding agency have

done some mock-‐ups”

Words that strike terror…


“Here’s how it could look”

Movie UI Design by Jayse Hansen


Getting the wrong side of the line only leads to conflict…

“Arrogant tossers, they just don’t get it!”

“Ha, they’re so wrong. This is a much beCer idea.”


Today’s Line








Setting out to raise the bar







“Mmmm. Nice concept, full of possibility. Will be fun to see how we make it work.”


So two key questions:

How do you do this cost-effectively? We already think we don’t have enough time for design – how do you make it worth investing in?

How do we ensure this process does not en5rely alienate design and development teams?


Three answers

Focus on generating facts, not opinions; and be lean about it

Enable and equip your design & build team, don’t tell them what to do

Don’t be precious – about your ideas, or being right


Focus on genera5ng facts, not opinions; and be lean about it


Flux[x] Labs


insight idea feasibility

design & development manufacture distribu5on


Hard to do, and a lot of risk

manufacture

design & development

feasibility

Idea

distribution

insight

Easy to do, and no risk

Star5ng to invest 5me & money


Hard to do, and a lot of risk

manufacture


feasibility

Idea

insight

Easy to do, and no risk

Star5ng to invest 5me & money


MVP = Minimum Viable Product

Q: What is the absolute minimum we can do to see if people actually value

our product?


distribu5on

Dim and distant past

insight

concept

feasibility


manufacture

Painful, but we got there…

Dragon’s Den

Give it to the press

Bankrupt factory

Dodgy catches

People bought it

Licensee liquidated

Rob Law’s facts were generated by pu#ng

his product in the hands of the press,

and sure enough they loved it.


He believed strongly because he had generated real facts

So what do the opinions of the dragons matter?!

The toughness of his journey was testament to the fact that his MVP could not be that minimal


Fortunately…

This now happens in days, or maybe weeks, but certainly not months.

The Lab’s job within a product development cycle is to generate evidence-based learning, to

help get the ideas right, and make good decisions based on facts

labs

Basic Insight

We found it really hard to find a whiteboard the

size we want and think that other people will

have the same problem.

labs

This leads to a value hypothesis that we can begin to test

“We think that people will value a premium service that makes and installs

whiteboards to a precise set of dimensions.”

labs

1.  Make a site that calculates the cost and puts customers in touch with us.��

2.  Get a phone!��

If people value this service as

much as we do.��Volume of people searching for it on Google��Requests for pricing��People who buy��

labs

The first MVP (c.2 days)

labs

The 2nd MVP

labs

The Lab’s Learnings

This is a viable, small, local business.

It would be a good idea to make the whiteboards erasable!

It is possible in a week to prove out a digital & physical business in a lean way

labs

“The High Street Bank”

A real life case study

labs

Amongst others, we created one

experiment designed to test

something that had been debated

for ages at the bank

labs

It was a thorny subject.

It involved using customers’

personal data to do something we

thought they would like and value.

labs

But would they accept it, or would

they go nuts and call the Daily Mail?

We put it l ive in a few weeks in an MVP to

several thousand real customers who didn’t know

it was just an experiment.

labs

But before we did…

labs

It was usability tested

It panned!

Only 24% of people said they would do it

labs

How many ACTUALLY did it in

real life?

96% of people just jumped right on in!


“What people say they will do and what they actually do is often

very different and can be greatly affected by their level of

awareness of the task at hand”


Market Research (quant and qual)

Usability Testing Prototype Testing

A/B Testing Multi-variate testing

True ethnography

MVP/Lean

Market Intelligence and behavioural data

Unaware Aware

Product/Service Maturity Level

Idea/Concept

Partial/Fully Developed

Is the User aware of the test?

The fluxx ‘Tested User’ Framework


A wide variety of opinions, ideas and

stories

Usability Optimising where there are multiple

options

Proving an idea one way or the

other

History

Unaware Aware

Product/Service Maturity Level

Idea/Concept

Partial/Fully Developed

Is the User aware of the test?

The fluxx ‘Tested User’ Framework

flux[x] @fluxxstudios @poleydee flux[x] @fluxxstudios @poleydee

The outcome of which is…

Armed with facts, a product development team can simply ‘tell’ they don’t ‘sell’

It’s hard to argue with, & people don’t want to

It’s equally obvious how to apply that data to influence the design later on


A key point here though is…

An MVP does not a design make

Which leads us to:

Enable and equip your design & build team; don’t tell them what to do


Briefing the team means focusing on the outcome

“Nice concept, full of possibility. Will be fun to make it work.”


Briefing the team

Present the trail of evidence •  A user-centred journey •  Help the team understand the

insight on which the product was founded

•  Don’t hide any facts •  Show your wrong turns


What it should be like, not what it should look like

Briefing the team

Describe, don’t prescribe


Create useful assets. Things that wi l l enable , not conf ine your des ign team

Draft Personas If you don’t know these, then the product you’ve developed isn’t worth the Omnigraffle it’s visualised on!

Product and Experience Principles Distil your experience of the product development learnings into principles that will help guide the design and build team


What we don’t say: “Yeah, we already prototyped it”

Product development should never be testing a UI, or a brand VI We ask questions like: •  Is the content valuable to our audience? •  Is the function that it performs valuable? •  How easy or low cost does it have to be to become, in

order to become valuable?


Which has led us to a unique design principle:

Make it as bad as you can get away with

(So long as you don’t get in the way of the core testing objective)

“I’ve never been asked to make my work

‘more sh*t before!”


How do you brief in how a product ‘feels’?

I’ll give you a briefing I’ve used many a time


Let me tell you why I love Virgin Atlantic


After a briefing like that, it should be easy to sum it up as something

as simple as: Brilliant basics, magic touches

… and a number of other principles to which a user experience or product would have to

conform in order to be the one that we believe customers will love


Finally

Our brief must be full of possibility

“It’s clear to us that people want a degree of serendipity; for the finding of information to have

a ‘fuzzy edge’ that allows them to stumble on something that they love, but weren’t

expecting”


Creating a product design brief with possibility

Always guide, never prescribe Set principles, not guidelines Design experiments, not UI Say how it feels, not what it does In short: Let the design team design it…


Finally: Avoiding the ivory tower

Don’t be precious – about your ideas, or being right


Talk about the dead ends Experiments never fail or succeed, they merely have outcomes


Take input wherever you can

Regularly take time to gather intelligence, ideas and product

thoughts from everywhere you can, and credit your sources


Be inclusive

Get the design and development team to develop the MVP

A RapidStart approach looks to get an

experiment out in under two days


Product Development can be a state of mind, not a department

For complex products where there is a high degree of uncertainty, it’s

an upfront investment


For new features in existing products, it can become a ‘spike’

in the existing process

Product Development can be a state of mind, not a department


Playing to each other’s strengths


[email protected]

Phew… J

Walking the Line: The Line of Product Development - Paul Dawson, Flux

Business

Transcript of Walking the Line: The Line of Product Development - Paul Dawson, Flux