The Role of Product Development, Fluxx

Friday 9th November
Paul Dawson, Partner at Fluxx

Walking the line: The Role of Product Development
Product development is, or at least should be, a user-centred discipline, but
often has a strained relationship with the design teams that have to bring that
product to life.

We’ll look in this session at what the role of Product Development is, how more
and more companies are thinking of their digital services as ‘product’, and the
very thin line Product Development has to tread in the user-centred design
process between empowering a design team, and potentially alienating them
altogether.

This document and its content is Copyright ©2012 Paul Dawson and UCD UK Limited. No rights are claimed over
third party images, all of which are used under ‘fair use’ and whose origin is acknowledged wherever possible.

flux[x] @fluxxstudios @poleydee

Walking the line:
The Role of Product
Development


The boring cred’s bit


A product & service
innovation company

Setting Strategy & Developing & validating Innovation practices &
Vision products long term change


Ideal outcomes from this session?

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

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

Product design “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)

 Strategy
 Ideas and insight
 R&D Concepts
 Developed & Validated Concepts
(Desirability, Viability, Feasibility)
 Partnerships and organisation
 Design & Build
 Operate


The ‘Non Product’ Approach

 Strategy
 Ideas and insight
 R&D Concepts
 Developed & Validated Concepts
(Desirability, Viability, Feasibility)
 Partnerships and organisation
 Design & Build
 Operate


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


But then they go one of two ways:
Exciting, interesting, innovative.
Empowered, creative, inspired
What if…
An exploration of why
What new opportunities 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?
Wireframes
Demotivated, dis-spirited, ‘done to’

Detailed, monotonous, not thinking for myself


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… 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 position to
judge before time starts
running out.

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

Agile approaches in non-product
thinking companies…

Things we
know we
can do

The unproven
ideas domain

Things we know our
customers value

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
Anything is possible

Empowered, creative, inspiring



I have a very tight, prescriptive brief


We might have had the ‘right ideas’


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


What we needed was an inspiring
brief with real possibilities
Research & Insight:

Now design something
magnificent

A clear product proposition:
“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 tired
parent arms and tired toddler legs and
make travel fun.”


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

Product
Digital UX development
.


Words that strike terror…
“We’ve developed a new brand,
and the branding agency have
done some mock-ups”

“We’ve had a
product design “The CEO had a
consultancy designer mock
working on it” something up”


“Here’s how it could look”

flux[x] Movie UI Design by Jayse Hansen @fluxxstudios @poleydee

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

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

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


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 entirely 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 generating
facts, not opinions; and
be lean about it


Flux[x] Labs


insight idea feasibility

design &
manufacture distribution
development


Easy to do, and Starting to invest Hard to do, and a
no risk time & money lot of risk d
i
s
t
r
i
man b
ufac u
ture t
design & i
development o
n

feasibility

insight

Idea


Easy to do, and Starting to invest Hard to do, and a
no risk time & money lot of risk
man
ufac
ture
design &
development

feasibility

insight

Idea


MVP = Minimum Viable Product

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


Dim and Painful, but we got Dragon’s Den
distant past there…

People
insight Bankrupt bought it
factory

Rob Law’s facts were
concept Give it to generated by putting
the press his product in the
hands of the press,
manufacture and sure enough they
design & loved it.
development

Dodgy
distribution
Licensee
feasibility liquidated catches


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


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
labs People who buy

The first MVP
(c .2 days)

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 live 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!

labs

“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”


The fluxx ‘Tested User’ Framework

True Market Research
Idea/Concept ethnography (quant and qual)
MVP/Lean

Product/Service Market Intelligence
Maturity Level and behavioural data

Partial/Fully A/B Testing Usability Testing
Developed Multi-variate testing Prototype Testing

Is the User
Unaware aware of the test?
Aware


The fluxx ‘Tested User’ Framework

Proving an idea A wide variety of
Idea/Concept one way or the opinions, ideas and
other stories

Product/Service
History
Maturity Level

Partial/Fully Optimising where Usability
Developed there are multiple
options

Is the User
Unaware aware of the test?
Aware


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

@poleydee

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


Briefing the team

Describe, don’t prescribe

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


Create useful assets.
Things that will enable, not confine your design 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


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

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


Playing to each other’s strengths

Phew… 

paul@fluxx.uk.com


The Role of Product Development, Fluxx

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (13)

Más de Fluxx

Más de Fluxx (7)

The Role of Product Development, Fluxx