Minimum Viable Web: MobX 2012

The Minimum Viable Web
Kristofer Layon

MobX — 17 November 2012
Berlin, Germany

Welcome to my presentation about the Minimum Viable Web. I am here to introduce you to
some useful product management tools and techniques to help you improve your web
products so that your users’ needs are met better, and also so your organization or business
is more successful. Aber zuerst, es gibt etwas, das ich für meine deutsche Kollegen
reparierien möchte. Ein bisschen “Bad German”, sozusagen...

Ich bin ein Berliner!
Everyone is probably familiar with JFK’s visit to Berlin during the Cold War, and his well-
known quote, “Ich bin ein Berliner” (I am a Berliner). Kennedy and his team were savvy
enough to want to appeal to the local residents, so the speechwriters were careful to include
this German phrase.

Ich bin Berliner!
Everyone is probably familiar with JFK’s visit to Berlin during the Cold War, and his well-
known quote, “Ich bin ein Berliner” (I am a Berliner). Kennedy and his team were savvy
enough to want to appeal to the local residents, so the speechwriters were careful to include
this German phrase.

The Minimum Viable Web | Kristofer Layon | @klayon | MobX — 17.Nov.2012

However, German speakers know that the grammar was incorrect. The correct translation is
“Ich bin Berliner”. When the article “ein” is used, the term “Berliner” refers to a jelly-ﬁlled
donut.

1. What is “minimum viable”?

2. Being responsive

3. Writing and following user stories

4. Prioritizing user stories

5. Developing business proposals

6. Sharing roadmaps and release plans


This is a great example of showing us that we can never know our customer well enough; no
amount of research can ever be enough. So my session focuses on tools and techniques that
you can use to help you understand how to design better for the people who use your
products and services, whether you are a designer, developer, project manager, or have
another role.

1. What is “minimum viable”?


What is a “minimum viable” solution? On the surface, it sounds like it is the least amount of
design and development that is necessary. But it is actually more than that: it is the least
amount of design and development that will meet your users’ expectations and your
organization’s goals.


As an example, I’ll highlight some mobile applications that I started to manage last year.
After designing web sites at a traditional university for over ten years, I was excited to get
more involved in mobile design. So I was excited to accept a new job at a very non
traditional, online education company, where I could be the product manager for Capella’s
mobile apps. It would allow me to work on mobile product design full time.


The apps that they already started working on looked great, and were already available to
their students. The apps allow students to participate in course discussions, and also provide
additional services including mobile library tools for searching for books and articles. The
apps were considered minimum viable versions. They didn’t have every feature that they
could have, but they were a start.

Can you imagine a telephone service that did not ring when there was a new call?


The trouble is, user satisfaction surveys and app store ratings told us that few customers
were satisfied with the initial releases of these apps. Feedback confirmed that our apps that
did not have notification options for updates or events. Users equated this to having a
telephone that does not ring when there is a new phone call.

We would be unhappy — is there someone waiting for us to answer?


Can you imagine if your phone did not notify you of a phone call, and needing to remember
to check it regularly to see if there is someone there waiting to talk to you? Seeing our apps
in this light made us realize that even though we thought they were successful in how they
were designed, the company had been wrong to not include notiﬁcations as part of the initial
release.

Similarly, without notiﬁcations our app appears to be OUT OF ORDER.


Our customers essentially told is that not including notiﬁcations made our apps appear to be
out of order. So even though the company had thought that they were a minimum viable
version to release for use, in hindsight we learned that this was a mistake. So how can you
know when it is safe to release a new product, and then how do you know how to improve it
later?

2. Being responsive


Today, the discipline of product management helps us maintain focus on user-centered
needs and the least amount of design and product that is necessary to satisfy customers. It
also emphasizes a continuous feedback loop of validating design with people, making small
adjustments, delivering new enhancements, and repeating for continuous improvement. And
starting with just enough to get going.

It is not the strongest of
the species that
survives, nor the most
intelligent, but the one

http://www.goodreads.com/
most responsive to
change.

Charles Darwin
1809-1882


As Charles Darwin put it, after studying variations in species that led to his theories on
evolution: isn’t the best design the one that is most responsive to change? Just as the species
that are most well-suited for their environments thrive (and the ones that are not either
adapt or die out), web products need to respond to their environment as well — an
environment that includes user expectations.

http://en.wikipedia.org/wiki/Darwin's_finches

Darwin saw evidence of evolution in the natural variation within species such as birds. Each of
these birds has a different beak shape, which Darwin understood was due to constant,
iterative changes that happened as the species who were best-suited to eat certain seeds
reproduced over time through natural selection. This process emphasizes the successful
details of a “design” over time.

http://chickenoreggblog.files.wordpress.com/2010/04/800px-wooly_mammoth-rbc.jpg

Whereas the example of the Wooly Mammoth is one of inability to respond enough to the
environment through adaptation. It likely died because of rapid environmental changes, or
perhaps being hunted to extinction by humans. In either case it was unable to respond to
environmental changes that threatened its success. We don’t want to our product designs to
be like Wooly Mammoths.

http://www.lukew.com

So here is the changing environment of web browsing: smartphone sales eclipsed sales of
PCs 2 years earlier than projected by Wall Street analysts. Boom! It’s the equivalent of an
asteroid slamming into the planet of web design and making many species of dinosaurs go
extinct. You do not want your web products to be among the casualties, do you?

Compe//ve
Analysis:
current

Capella Phoenix Walden Liberty Ashford Strayer

iPhone
App
Store 2.5 3.0 2.5 3.0 4.0 n/a

Android
App
Store
(Google
Play) 2.3 4.4 2.5 3.5 4.0 n/a

Discussion
read

Discussion
write

NoAficaAons:
grades

NoAficaAons:
reply
from
instructor

NoAficaAons:
reply
from
classmate

Course
media
(docs,
A/V,
ebooks)

Campus
news

Library

Register
for
courses

Tasks

©
2012
Capella
Educa/on
Company
—
Confiden/al
—
Do
not
distribute

So the first technique that I encourage you to use is what I did when I started to improve this
mobile product. I took a closer look at our environment, including our competition. I did this
by looking at app store ratings of the iOS and Android versions of our mobile apps. Our
competitors with notifications had higher customer satisfaction.

Compe//ve
Analysis:
2013

Capella Phoenix Walden Liberty Ashford Strayer

iPhone
App
Store 4.0 3.0 2.5 3.0 4.0 n/a

Android
App
Store
(Google
Play) 4.0 4.4 2.5 3.5 4.0 n/a

Discussion
read

Discussion
write

NoAficaAons:
grades

NoAficaAons:
reply
from
instructor

NoAficaAons:
reply
from
classmate

Course
media
(docs,
A/V,
ebooks)

Campus
news

Library

Register
for
courses

Tasks

©
2012
Capella
Educa/on
Company
—
Confiden/al
—
Do
not
distribute

Today I believe that adding notifications to our mobile apps should increase customer
satisfaction. In other words, without notifications in our initial release, our mobile solution
did not meet the minimum expectations that our customers had. Though I don’t mean to
suggest that competition should be your only roadmapping guide; you don’t want to
participate in a feature war. But competitive analysis is one good way to determine how to
improve a product, and this type of visualization is also a good way to obtain support from
clients and business stakeholders.

How can your design (and organization)
weather environmental changes?


So how can product management help your or your client’s web product succeed, especially
when technological and customer preference changes are rapid?

Don’t set out to redesign.

Respond and reprioritize.


It can seem daunting to react, thinking that product redesigns are necessary to succeed. And
sometimes that is the case. But before reaching that point, decide instead to just respond and
reprioritize what you do. You may be able to respond enough to be successful without
needing to fully redesign your solutions.

3. Writing and following user stories


User stories are one of the most important tools for keeping design and development teams
focused on environmental changes and user expectations.

User stories:
Deﬁning user needs in human terms


I’d like you to focus on writing and solving user stories rather than just thinking of good
technical solutions. User stories ensure that your design solutions are properly focused on
solving human needs. By deﬁning and maintaining a backlog of user stories on which to
focus your design and development, you have a disciplined way to iteratively improve your
web site or app over time.

User stories help you focus your success
on making a real impact, not just
delivering solutions.


Good user stories focus exclusively on user’s human needs, but not just that. They should
also incorporate business goals. User stories should help guide design and development in
ways that improve customers’ user experiences in ways that also improve organizational or
business goals.

Bad

Students visiting our web site will use a
jQuery web form to interact with our event
registration, and will get there by seeing
Forms in the top nav.


Here’s a poor example of a user story. It mixes up a developer’s personal bias toward using
jQuery with what a user actually needs to do. But the fact is, people visiting a web site are not
seeking to interact with jQuery. They’re coming to a site to learn something or get something
done. So help them get that done in the leanest, most responsive way possible. The
developer’s preference may not necessarily be part of the best solution.

The right ingredients

•Output: what you make
•Outcome: the UX results of using what
you make
•Impact: the business results of using
what you make


By focusing on output, outcome, and impact, you can write user stories that deﬁne what your
solution needs to solve. That way you’ll have a user-centered way to measure success.
Because success isn’t about delivering jQuery, it’s about increasing outcomes that have a real
impact on organizational goals.

Good

As a student, I am able to register for an
event on your web site.


So this is a good start to a user story. It deﬁnes a basic output: an event registration.

Better

As a student, I prefer to register for an
event on your web site using my
smartphone.


This is slightly more reﬁned, because it deﬁnes an outcome: it puts the desired output in the
context of a desired outcome, being able to generate the output on a smartphone.

Best

As a student, I prefer to register for an
event on your web site using my
smartphone. I am more likely to register
that way and attend the event.


And this user story is an example of one that deﬁnes not just output and outcome, but
impact of the design. You’re not just going to measure registrations, or even mobile
registrations. You’re going to measure success by how many people attend the event, and of
those how many were able to register on their preferred device of a smartphone. This goes
beyond the typical measure of success: web analytics.

4. Prioritizing user stories


By interviewing and surveying users, noting their preferences and expectations, and then
writing good user stories, you can develop a backlog of user stories. This backlog is what
your team can focus on as they determine how to design and develop product improvements
that will increase customer satisfaction. But what happens if you have too many stories to try
to solve? Then you need to prioritize.

Determining priority:
Maslow’s Hierarchy of Needs


I suggest taking a look at Maslow’s Hierarchy of Needs as a way to understand how human
needs are met, and a framework to assess which user stories might be the most important
ones to work on ﬁrst.

http://en.wikipedia.org/wiki/Abraham_Maslow
Abraham Maslow
(1908-1970)


Abraham Maslow was a pioneering developmental psychologist whose research and writing
focused on a theory of a hierarchy of human needs, motivation, self-actualization, and
potential.

Abraham Maslow, A Theory of Human Motivation, 1943


This graphic of Maslow’s theory of human motivation illustrates these needs in a pyramid,
with the most fundamental needs as the foundation at the bottom. Each layer needs to be
met before you are able to focus on the next level of needs. The ﬁrst four layers are basic or
“deﬁciency needs”; the top layer is unique and the most advanced, considered “being needs”.

Local storage Ofﬂine

Web sockets Transitions
HTML
5

Performance
Respond Share
Read Pinch+Zoom
See Navigate
Mobile
Kristofer Layon, A Theory of Human Motivation, 2012


I think this hierarchy can be used to systematically analyze features or enhancements to the
web, too. We need to be able to see and navigate above all else. Then we can focus on
reading, and thereafter responding and sharing. After that, how fast or well this happens
(performance) is important. Then there are “extras” like HTML 5 and JavaScript.

http://mobile.smashingmagazine.com/2012/08/22/separate-mobile-responsive-website-presidential-smackdown/

Brad Frost liked my suggestion and created this version for a Smashing Magazine article that
he wrote in August 2012: start with giving people access to data and information, then help
them interact with it, the improve performance, and focus on extra enhancements last.

You can have more than one priority,

but everything can’t be your top priority.

Product management is about identifying needs

and managing priorities to maximize satisfaction.


As you try to assess opportunities and priorities for improving the design of your product,
there are other ways to analyze how products satisfy customer needs and expectations. Let’s
take a look at another way to think about this.

Kano Model


Another useful tool for analyzing product attributes is the Kano Model, originally developed
for the Japanese auto industry. It breaks product attributes down into three categories. Note
that the different attribute categories yield different results because of customer
expectations.

http://www.van-cafe.com/shop/images/22S.419.091C.jpg

A quick explanation by way of analyzing a car: a basic feature of a car is a steering wheel. In
other words, not having a steering wheel is a fundamental problem. It’s a basic requirement,
so long as cars are actively steered by a human driver (maybe someday they won’t be). But
having a steering wheel doesn’t get your car high consumer ratings either.

http://wac.450f.edgecastcdn.net/80450F/973thedawg.com/files/2011/11/fuel-gauge.jpg

A performance attribute of a car is fuel efficiency. The less fuel it needs, the less it costs to
operate the car. This is enhanced performance. So for some customers lower fuel efficiency
results in lower product satisfaction. But high fuel efficiency results in higher satisfaction. So
it’s much less binary than having, or not having, a basic attribute.

http://1.bp.blogspot.com/-7y-e8Fm1_Ik/T6rYexg6AOI/AAAAAAAADOA/ELLTW_Lc5XQ/s1600/Crazy+Hair+Kelli.jpg


A delightful feature of a car could be a convertible top. Putting it down lets you sit in the sun
and have the wind blow through your hair. It can make a car a lot of fun to drive, but it
doesn’t aid in performance and it is also not a basic function of a car. So most cars lack a
convertible top, but that doesn’t adversely effect product satisfaction. That’s what
distinguishes a delightful feature.


In approaching a product, we can see how balancing feature attributes and priorities with the
Kano model can help achieve higher product effectiveness and satisfaction. If we are building
a car, it has to start with basics like a frame.


Then it needs other basic attributes: additional body parts and that darn steering wheel.


And it most certainly needs wheels -- another basic attribute of a car.


A windshield is mostly a basic requirement as well. But it also has performance attributes: it
helps make the car’s shape more streamlined, which aids in energy efficiency.


An add-one feature like a light bar on the roof is mostly a desirable attribute. Some people
might think it looks cool; it’s not a basic or performance feature.


The right balance of basic, performance, and desirable features makes the owner of the car
happy and satisﬁed. It’s a solution that is biased towards functionality over the extra features
or ornamentation of superﬂuous design.


On the other hand, the wrong balance of the three Kano attributes can get you in trouble.
You don’t want to prioritize performance and desirable features until after you have all of the
essential basic features delivered. Desirable or performance features cannot make up for a
missing basic feature.

http://www.dilbert.com
Clients and executives like graphs!


A blend of these tools and visualizations are very helpful. And using charts and graphs can
be very helpful and persuasive. As a designer, they may not be your ﬁrst choice of medium
for communicating your ideas, but you need to recognize that well-presented data can help
you meet your product design goals. It’s very important to communicate in ways that clients
and stakeholders understand to gain their support.

Kano Analysis
5
4

http://www.veteranautocsodak.hu/kepek/trabant60126.jpg
3
2
1 Basic Performance Delight
Trabant
Kano attributes

Let’s take another look at how Kano analysis can be used to assess product satisfaction. This
example begins with the Trabant, an East German car produced until the late 1980s when
East and West Germany were reuniﬁed. As westerners, we would probably assess this product
in this way: all 1s on a 5 point scale.

Kano Analysis
5
4

3
2
1 Basic Performance Delight
Porsche
Kano attributes

Similarly, we might determine that a Porsche, another German car, would be all 5s. It not
only meets the basic requirements for a car, its performance is high, and it’s beautiful and
delightful to drive.

Kano Analysis
5
4

3
2
1 Porsche
Basic Performance Delight
Parent of 3 children
Kano attributes

On the other hand, it’s important to know your customers. What if the customer I’m trying to
satisfy is a parent of three children? Then a Porsche would rate lower on basics— not enough
room for those kids. Performance-wise, it’s also an inefficient vehicle for family tasks like
getting groceries. It’s still delightful, but not a solid 5 points for this customer.

Kano Analysis
5
4

3
2
1 Minivan
Basic Performance Delight
Parent of children
Kano attributes

Whereas a minivan, which is decidedly unexciting and common, might rate highly in all
categories for a family with several children. It has a lot of room, is fuel efficient, can haul a
lot, and has doors you can open remotely. It’s a great mix of basic, performance, and delight
for that customer. So use visualizations like this to help your boss or clients understand your
web product’s satisfaction.

Kano Model


So going back to the other type of Kano graph, focus on delivering all basic features to your
users ﬁrst. Then determine how to add performance or delightful features as needed. Not
delivering a basic feature well will result in users thinking your product is inadequate or
broken, no matter how great the performance or delightful features are.

Kano Model


But completing all basic requirements, and then adding something that enhances
performance or delight, should make users satisﬁed and hopefully very happy with your
product.

5. Developing business proposals


Another way to communicate with clients and stakeholders is to ﬁnd other ways to visualize
the environment of your product, and ways to make an impact. Often other types of graphs
and business summaries can be helpful.

Percentage of Capella customers with smartphones

100

75

50
79% today
25
81% by Q2 of 2013
2012 92% by 2014+
2013 0
2014+

Communispace research ﬁndings, October 2012


For example, people often ask me how to convince a client or employer to adopt responsive
web design. My answer is this: don’t spend a ton of time going over how it works technically.
Instead, focus on communicating the demand for it. Visualize this and explain how
responsive design can be used to meet customer needs and drive more business success.
This is something that people understand much better than just how responsive design
works. Because RWD is just a technique that helps you deliver more meaningful results: site
visits and completed transactions.

Analysis of advisor call attempts:
non-participation at the beginning of a new course

• 5,300 phone call attempts per term
• 21,000 phone call attempts per year
• Average length of a call attempt: 1.5 minutes
• 31,800 minutes (or 530 hours) per year
• 13.25 weeks (or 3.3 months) per year
• Equal to one full time position every four years


Here’s another example of a slide that isn’t particularly sexy. But showing data like this can
really make you look good. Dig deeply into business processes, and show how a design
enhancement can save staff time or make something easier for your clients and customers.
These are the things that people want to improve; technology itself is not the end, it’s just
the method to help achieve success.

6. Sharing roadmaps and release plans


Finally, organizing your backlog into priorities should also include maintaining roadmaps and
release schedules for your planned improvements. Because sometimes with clients or
stakeholders, you encounter the opposite problem of having to sell good ideas: the problem
of them wanting you to get all of your good ideas done right away. But often that’s not
possible due to resource constraints.

Mobile Roadmap + User Story Backlog
Rev. November 12, 2012
Kristofer Layon, Mobile product manager

Highest Priority

Library:
hours; ask a librarian;
search for books

Social:
purpose and goals;
edit proﬁle

Currently in development


So use a roadmap to communicate how you intend to improve your web site or app over time.
Use this to explain how your planning has been thoughtful, how you’ve determined a variety
of user expectations that you would like to meet. And you are starting with the top priorities
and working you way to other improvements in the future.


Highest Priority

Library: Courses:
hours; ask a librarian; read assignment
search for books descriptions

Social:
purpose and goals;
edit proﬁle


Academic plan:
register for courses

Course discussions:
unread indicators,
read/unread status

Courses:
messages
(AKA “course email”)

Courses:
read the syllabus


I like to use product roadmaps that show what is being worked on right now in the upper left
corner, and then add items that I plan to have the designers and developers work on next.


Highest Priority

Library: Courses: Notifications:
hours; ask a librarian; read assignment assignment grade is
search for books descriptions posted

Social: Notifications: Notifications:
purpose and goals; on/off, classmate replies to
edit profile set event preferences discussion post


Academic plan: Notifications:
Notifications:
register for courses instructor replies to
course grade is posted
discussion post

Course discussions: Notifications: Notifications:
unread indicators, new course message financial aid is
read/unread status awarded

Courses: Notifications: Notifications:
messages advising alert for non- discussion post is due
(AKA “course email”) participation

Contact: Notifications:
Courses:
share questions, ideas, advising alert for not
read the syllabus
problems (Get Satisfctn) being registered


After that, I show items that might be coming up later. Subsequent groups of user stories
might not have as clear of a prioritization within them. Certainly, some improvements might
need more customer validation, user experience design, or architectural work to determine
whether when they can be designed and built.


Highest Priority

Library: Courses: Notifications: Academic plan: Timeline: Courses:
hours; ask a librarian; read assignment assignment grade is program map time-based UX for profile pics in
search for books descriptions posted prospects & learners discussion posts

Social: Notifications: Notifications: Task list:
Offline browsing with
purpose and goals; on/off, classmate replies to read, edit, and add
online sync
edit profile set event preferences discussion post tasks


Academic plan: Notifications: Notifications: Timeline:
Notifications:
register for courses instructor replies to assignment is due integrate Capella
discussion post Facebook, Twitter

Course discussions: Notifications: Notifications: Notifications: Timeline:
unread indicators, new course message financial aid is advising alert for initial integrate enrollment
read/unread status awarded advising appointment counselor events

Courses: Notifications: Notifications: Notifications:
Course discussions:
messages advising alert for non- discussion post is due advising alert for
replies to you
(AKA “course email”) participation change in acad. plan

Contact: Notifications: Notifications:
Courses: Course discussions:
share questions, ideas, advising alert for not task list alerts
read the syllabus collect posts
problems (Get Satisfctn) being registered


As you move into the future, find a way to visualize how the further you look into the future,
the less certain the team should be about the user story backlog. As the environment
changes, you need to be able to drop some ideas from your backlog. An idea that looks great
today might seem silly in 6 months to a year. Roadmaps should evolve over time.


Highest Priority

Library: Courses: Notifications: Academic plan: Timeline: Courses:
hours; ask a librarian; read assignment assignment grade is program map time-based UX for profile pics in
search for books descriptions posted prospects & learners discussion posts

Social: Notifications: Notifications: Task list:
Offline browsing with Units:
purpose and goals; on/off, classmate replies to read, edit, and add
online sync intro. and objectives
edit profile set event preferences discussion post tasks


Academic plan: Notifications: Notifications: Timeline: Getting started:
Notifications:
register for courses instructor replies to assignment is due integrate Capella introduction and
discussion post Facebook, Twitter expectations

Course discussions: Notifications: Notifications: Notifications: Timeline:
Units:
unread indicators, new course message financial aid is advising alert for initial integrate enrollment
e-books
read/unread status awarded advising appointment counselor events

Courses: Notifications: Notifications: Notifications:
Course discussions:
messages advising alert for non- discussion post is due advising alert for Career advising
replies to you
(AKA “course email”) participation change in acad. plan

Contact: Notifications: Notifications: Social:
Courses: Course discussions:
share questions, ideas, advising alert for not task list alerts participate in iGuide
read the syllabus collect posts
problems (Get Satisfctn) being registered community discussions


At the end of the roadmap should be ideas that may be purely speculative; perhaps you
haven’t even validated these at all with actual users. Because sometimes you have innovative
ideas that do not come from customers, and those might be the most successful to deliver in
the future. Keep those on the roadmap, and find ways to prototype those ideas and see
whether your users will respond to them favorably.

Mobile Release Plan

Q4
2012
/
Q1
2013 Q2
2013 Q3
2013 Q4
2013
Library Discussions NoAficaAons Write
to
discussions
What:
Search
for
books
and
What:
Know
more
informa/on
What:
Opt-‐in
for
real-‐/me
What:
The
Bb9
rollout
should

ar/cles;
ask
a
librarian. about
discussions
(quan/ty,
no/fica/ons
re.
grades,
be
completed,
so
I
want
the

Why:
Make
it
more
convenient
unread,
etc.) replies,
fin.
aid. mobile
experience
to
be
as

to
begin
research,
and
easier
Why:
Our
discussion
UX
s/ll
Why:
This
is
the
top-‐requested
good
as
it
can.
to
contact
a
librarian
for
requires
a
lot
of
explora/on.
mobile
capability
of
our
Why:
It
will
be
cri/cal
to
not

assistance. We
can
do
beUer
to
convey
learners
aXer
a
full
discussion
have
unfinished
details
for

ac/vity. experience.
discussions.
Social
Profile
What:
Edit
/
add
social
profile,
Tablet
UX Course
content Other
priori.es
as
.me

including
purpose
and
goals. What:
Expand
access
to
course
What:
Read
course
syllabus
permits:
Why:
Increase
opportunity
for
and
campus
content
and
and
assignment
details. •
Performance
learners
to
access
their
social
interac/ons
via
tablets. Why:
Delivering
a
full

enhancements
profile,
encouraging
personal
Why:
Our
tablet
use
is
discussion
experience
isn’t
•
Tasks
development
and
social
increasing,
so
we
need
to
keep
enough;
we
should
be
•
Course
registraAon
engagement. our
eye
on
tablet
UX
and
providing
access
to
more

deliver
more
via
browser
or
course
content.
This
starts

na/ve
apps. with
more
basics.

©
2012
Capella
Educa/on
Company
—
Confiden/al
—
Do
not
distribute

Another format for roadmapping is to maintain a quarterly release plan. Depending on your
audience or the context of the presentation, it might be more useful to focus in more closely
on the top priorities for the next few quarters. Use a release plan to do this, and list the top 2
or 3 priorities per quarter. Again, as you look further ahead, emphasize to your audience that
this priorities might change as you learn more.

Minimum Viable Design:

• Start with people.
• Design from your content out.
• The least amount of design and
development necessary to meet a need.
• Iterate and add only if more is requested.
• The result: a more simple, lightweight
solution.


Minimum Viable design starts with human needs and the content or services that people
really need. It priorities content in the hierarchy, and only adds as much visual design as
necessary. The results should aim to work on any device. If they work on a small screen, they
will work on a large screen (and can always be progressively enhanced further for desktop).

Product Management:

• Get away from your desk – talk to people.
• Get market data, then write user stories.
• Prioritize, estimate, prototype solutions.
• Road map product enhancements.
• Be agile: iterate, deliver, evaluate, and repeat.


Web Product management is the set of tools and processes that can be used to develop the
right Minimum Viable Web for your customers. They are also used to develop strong
relationships with everyone involved: customers, stakeholders, designers, and developers. It’s
product management’s job to make everyone understand your web product’s direction.

http://www.wengerna.com/

By using market data to inform usefulness, setting priorities, and learning how to say no to
things that users don’t really need, you can avoid designing a mobile app or website that
ends up looking like this: trying to do everything for everyone that, in the process, ends up
being too cumbersome to make anyone happy.

http://pragmaticmarketing.com/

Most importantly, by focusing on customer expectations and user stories, your designers and
developers can avoid falling into the trap of thinking that their insight, creativity, and
technical expertise are enough to develop successful solutions. Because in the end, your
opinions are not as important as your customers’. And getting something done well isn’t the
true measure of success; it’s whether what you’ve designed and delivered is meeting or even
exceeding expectations.


If you are interested in approaching online product design from a Minimum Viable approach,
you might want to check out an article that I wrote in July 2012 for A List Apart, “Product
Management for the Web”.


I also wrote a book for Peachpit Press last year entitled “Mobilizing Web Sites”. It starts with
suggestions that you can follow to support your content, navigation, readability, encouraging
you to get into mobile design by focusing on your users’ most basic needs ﬁrst. Writing this
book is what got me focused on product management and the idea of the minimum viable
web; perhaps it can help you make that transition as well.

Herzlichen Dank!

@klayon
kris.layon@gmail.com
kristoferlayon.com


Minimum Viable Web: MobX 2012

Recommended

Recommended

More Related Content

Similar to Minimum Viable Web: MobX 2012

Similar to Minimum Viable Web: MobX 2012 (20)

Recently uploaded

Recently uploaded (20)

Minimum Viable Web: MobX 2012