This Workshop is about lean ux lean ux focusing on
bridging together, design product and engineering
and building agile teams teams
focused on their agility. Not the process of agile and doing. So
by building a collaboration that is
cross-functional, and iterative and built a shared understanding
amongst those teams. And I like to start the
workshop with this slide.
What it says at the bottom, there is the other day. My dog got attacked by a raccoon, so I
set up a trap and this is what I call it. And the
reason that I like this slide is because just because
we are designing a product to do something
specific to be used by a customer in a specific way.
We really have no idea how that product is going to be used until
we actually put it into the field and test it. For example, in this case,
the goal was to catch a rat.
Who was bothering the dog? Instead we caught the dog. And so
our job as creative
product development, people is to figure out how to
best meet our customers needs. How to best meet our businesses
needs, and 2D risk, the product development process.
So that when we invest in the production of these
products, they stand the greatest chance of success.
And that's what this Workshop is all about. How do we do risk the product development process,
how do we create successful delightful products that meet both our
customers needs and our businesses needs in the most effective
and the most efficient way possible.
And so we're going to start the story of how to do this with a story of failure,
and there are lots of stories of failure out
there. One that I like to talk about is the story of plancast
plancast is a social was a social event sharing site
that launched in 2010.
I believe and the purpose of plant cast was to create a
service that allowed you to sign up.
Create an account and then broadcast out to your social network, where you're going to be,
what you're going to be doing and what you'll be doing. Once you're there is a, for example,
I'm going to this particular meet up. I'm going to this conference
and people can sign up and follow you on
plancast can get a steady stream of the events of where you're going
to be.
Now the interesting part about this is that this site launched two, tremendous Fanfare and
hype. Lots of a claim by the folks in Silicon
Valley because the folks who launched this company were
serial entrepreneurs, from Silicon Valley, and the company launched
and such meteoric, rise and success. And then over time, it didn't
live up to the hype.
And flatlined and usage, went down. And at the end, their assets were
sold to a larger company. So plancast still exists to some extent,
but certainly not in the vision that it once was as
the startup Founders, had imagined it. And what's fascinating, is that in
2012, the founder of the company, wrote a post mortem
about Plan cast on TechCrunch and it was a
very detailed post-mortem that talked about why they
failed and it's very
appropriate, that they actually wrote that on TechCrunch, because that's exactly where they launched, they launched on TechCrunch
and they died, essentially on TechCrunch, and I've pulled a series of
quotes from that post-mortem that talk about
what didn't go well in the execution of the vision for plancast. And the one thing I
want you to keep in mind as you're going through these quotes, is that the team
worked for five months before they launched a single
thing, into Market, five months of their time of somebody else's money
and effort before they launched a single feature
into Market. Here's the first quote, while the initial
launch and traction proved extremely exciting, it misled us
into believing, there was a
Archer Market ready to adopt our product. So they launched and the hype is huge and the
TechCrunch Crowd Goes Wild and they feel like they're getting a
ton of feedback and traction.
But what they're not testing to see is who is actually testing the site
and working on it. And it turns out in retrospect that it was early adopters,
VCS other entrepreneurs and Friends within that
Silicon Valley bubble.
And so they're looking at their numbers and they're seeing this, a hundred thousand people have registered and over
230,000 people. Visit each month these days,
these are called vanity metrics and they're called vanity metrics because they
make you feel good about yourself. But they don't actually tell
you anything about how your product is performing. Whether it's working well or
working poorly of these hundred thousand registrations, how many
people have actually shared a plan
How many people have actually followed somebody on the service? How many of these people
come back a second time or third time? And then for the second
month and the third month, these numbers don't tell you that. So
they make you feel good. But they don't tell you whether or not you're actually seeing any traction
for your product and it gives you that false sense of success and a false sense of
product Market fit.
One of my favorite quotes is this, people often tell me, I like plancast, but I never have any
plans to share this entire system was built around a social
object called a plan. I'm going to do something.
It turns out after they launched, they learned that
people don't have these plans to share.
The problem statement they set out to solve was that the average individual doesn't have enough
insight into all the social opportunities going on within their Social Circle.
And they didn't want people to miss out, but this was a personal intuition made by the
founders. There was no proof that there was a wide Market need and no
upfront. Research was done to validate the problem.
And so after they launched, they find out that they built the service to share thing that people
don't have.
What's even more interesting?
Is that for those people who did actually have a plan to share for the few individuals that did
actually have a plan to share it, turns out that sharing a plan
doesn't give you that same warm squishy, feeling that sharing a
picture of your kid, or your pet, or your meal does on
all the other social networks.
And again, five months of work to launch, only to find
out that people don't really get anything out of sharing these
plans and as the system grew over time and they continue to develop it. They
didn't see any social sharing and they couldn't understand.
Why was there an opportunity for them to learn this before. They
spent five months building the system and the site.
The last quote, I want to use from this is this one, the
team made a subjective decision before, launching
not to have an invitation feature.
They didn't know which features to build and so they took a philosophical stand against
invitations for fear of being lumped in with the evite's and the other invitation
services that are out there today. And when they
launched, and they created a system where some people are actually sharing their plans
about where they wanted to be. They created an environment
where people were aware of all these great things that were happening in their Social Circle.
But didn't feel welcome to attend any of these events. They didn't feel invited to
them in essence, creating an anti social network in the
process. And again, was there an opportunity for them to
learn this, in advance of spending five months, worth of work, and of course, the answer is
yes. Now what's interesting is that that's a start-up context,
but whether you're in a start-up context or in an Enterprise context, companies are
still working with old assumptions. The old assumptions that you have to
design everything.
Up front. You have to specify everything up front and make sure that everything is
in place and defined before you ship it, off to production
or to the printer.
At the assumption is that we're building bridges. You have to determine where we're going to start and where
we're going to end, and what's going to happen in between before we can lay a
single brick.
And the software context people are still thinking about this. We're still delivering
software.
In fixed format on a disk where we have an opportunity to design or build for
six months, or a year or 18 months and then launch. And then
people will go by this physical artifact and install the
software. And then we have another year 18 months before we can update that and
learn anything and move that forward.
But that's not our reality. A reality has changed
software. Delivery can now happen through a variety of different
channels, the least of, which is actual physical
material to deliver it on, we're delivering software now through the
web and through mobile app stores and through any other channel that
can get those bits onto people's devices in the fastest way
possible.
And this is fundamentally changed the way that software is being
developed consumed and needs to change. The way that software
is being developed because this is the new reality.
Software is continuous.
It's never finished. We're no longer working towards
that disc that we put on a box and put on a Shelf.
We're no longer delivering a finished product instead, we're delivering
continuous incremental improvements.
And that fundamentally changes our ability.
In learning what we should build and what we shouldn't build which needs to
change the way that we develop products to put a fine point
on it. This is how often Amazon pushes code to production.
every eleven point six seconds, Amazon pushes
codes lie,
To production.
Now, they're not refreshing the entire Amazon ecosystem, every eleven and a half seconds,
they're pushing small bits forward and because they're pushing these
small bits, they get an opportunity to learn. Whether those small bits actually
made a difference where they learn something, whether they made a change
and if they did, they can scale that out further or
they can optimize that and then scale it out. But if they didn't make a difference,
They can roll that back.
And it's those tiny bits of risk that allow them to continually
improve their system. It to continually optimize and build better
products.
And this gets us out of this mindset of the model year, the
nature of software being continuous. The nature of our learning
being continuous because you can deliver software on a regular basis like that
you're building a continuous learning Loop, that gets you out of this
mindset of the model year, were no longer thinking we shouldn't be thinking
how many features can be crammed in to the next iteration of our
product.
What will people pay for the next time we go to sell them? Something
that mind change mindset has to change because we're no longer making
copies of a known thing will continually evolving the
system.
And we're doing that through that continuous feedback loop.
Which is the reality of how software is delivered today.
And so what processes allow us to learn to
work this way and to take advantage of all this new information
lean ux is one of those processes and ux to talk about a
properly we have to talk about three different things we have to talk about agile software development.
We have to talk about Lean Startup and we have to talk about
lean. First thing I want to mention is agile software development.
Now without going too deeply into agile software development
I want to talk about why it came to be that these 17 gentleman software engineers,
About in the year 2000 were frustrated with the way
that software is being delivered. They were missing deadlines. They weren't
meeting customer expectations. They were continually negotiating with their clients
about what they were building and how things were changing and evolving as they
were writing code and they figured it had to be a better way.
And so they send it a mountain and Utah
where the air was thin. And they spent a few days up in the mountain,
discussing better ways to do this. And when they,
Descended from the mountain and he most biblical way they came
down with the agile Manifesto. Now the agile Manifesto is a fairly short
document and if you've read it, you'll know that there's
nothing in there that talks about process. There's nothing in there that
says, you will stand up everyday 9:30 for 15 minutes with your
colleagues. You will work in two weeks Cycles. You will have a retrospective. None of
these things are in there. In fact all the agile Manifesto is is a
set of principles.
Goals and philosophies, for approaching work, in their
case, it was software design.
And it boils down to these core. Four principles.
And what these guys were saying is that we value the things on the left,
more than we value, the things on the right. It doesn't mean that there's zero value
over here on the right, it just means there's more value on the things on the left and
that's where we should focus. Our efforts.
The first of this is individuals and interactions over processes and tools.
We all use processes and we all use specific tools to get our jobs done.
Inevitably those processes and tools boxes into a point where we can't make any
more progress.
There's more value in standing up going to talk to your colleagues and interacting with
them in real time to get you unblocked and moving forward
and not to get blocked and say well, the process doesn't allow me to take the next step until we unblock the
previous step.
There's more value and standing up and having an interaction with an individual.
There's more value in working software than there isn't comprehensive documentation.
Our customers use working software, they don't use comprehensive
documentation. How can we get to working software faster?
Or how can we least get to an approximation of working software faster,
as opposed to building a set of comprehensive documents that describe an
experience that may or may not work for our customers and our business in the future. There's
more value in working software than there is in documentation.
There's more value and customer collaboration than there is in contract negotiation
at the beginning of every engagement, where they work in house, where they work in an agency, you're going to
make a series of commitments to your customers, whether external
customers or internal customers.
and if you negotiate every bit of a contract and a commitment level up front,
you're going to find out as you start to build the product. That things are not going to line up. Exactly how you
imagine them to be.
And so you're going to renegotiate that contract on an ongoing basis.
Instead, there's greater value and collaborating with our customers throughout the software development process,
to let them know what we're learning, what we need to adjust and
allow them to make the priorities and the decisions that need to be made
as new information is revealed.
Finally responding to change is more valuable than following
a plan. It doesn't matter what process you use
to develop your products today. It doesn't matter whether using lean
or agile, or Six Sigma or whatever it is you're going to have
a plan. You're going to make a plan that says, we're starting at Point a and we're going to end
at point B.
Now along the way things are going to change, you're going to
learn new things. The features that you thought were
simple may turn out to be complex. The complex features may turn out to be simple.
Your competitor May launch the exact same thing that you're working on and do
it better than you while you're still in development.
The market you're building for Macy a fundamental change.
In the way that it's configured. It may crash. I'll give you an example. I used to work at a
company called the ladders. The latter's was a job board that cater to people who made
$100,000 or more. I started working there in October of
2008
and we had a clear plan for the future, focusing heavily on our financial
services and our sales job Seekers and jobs
in that system.
Lehman Brothers collapsed a few weeks after I started at
that job. All of a sudden our ecosystem, which was fairly
well, balanced between job Seekers, and employers and recruiters
all of a sudden, looks like this.
Tons and tons of job Seekers and no jobs.
We have the option to heads down. Follow our plan. We had a plan, 18
months roadmap the whole thing. But instead, you have to
look up periodically and regularly, and respond to that
change, and adjust your plans, to make sure that you're building the best
product for your Market as it exists today.
And that's the key to being agile, right? We're not focusing on a
process of doing an agile process. We're focusing on agility on
being agile and that is responding to change over following a plan.
Now, what's interesting is that user experience
design, product management, content strategy, all
of the disciplines that today make up the difference between a successful
product and an unsuccessful product. We're never factored in
during agile.
Agile was conceived by a bunch of Engineers.
So then how do we bring these disciplines together?
In a way that values, all of the things that the agile Manifesto talks about.
And that's we're going to talk about
The next thing I want to talk about is lean.
Lean has two fundamental principles. That underlie the entire way
that it's built.
The first is that you're always moving from doubt to certainty.
It's an inherent and humble admission by
you, your team, your manager.
That we don't have all the answers upfront to the way that we need to solve this
particular business problem, and so we're always moving from doubt to
certainty.
And the way that we move from doubt, two, certainties the second principle and that's in working in
small batches. So we're always taking small steps
towards certainty, moving out of doubt.
This is that Amazon model, they take their small steps every eleven
point, six seconds. In other words they're baking the cupcake
before they're making the cake right. Is this a good cupcake?
Is this a good recipe? Let's find out. And if not let's refine it
and then scale it out. This was the foundation for lean.
When it was developed in the 1950s, at Toyota by taiichi Ohno and
the rest of the folks at that organization and post-war Japan was struggling to keep up with
the American car manufacturers.
And they realized that they couldn't compete on scale.
And so they decided to compete on variety and efficiency and
they built the idea of the lean model, the Toyota production system,
which essentially Works to remove waste
from the process. Anything that doesn't add value to the
business and to the customer is waste. And as we take
those small steps from doubt to certainty, we're
removing waste from the process because we're not building things that people
don't want.
Now and what is possibly the ugliest infographic ever made?
This is the Toyota production system. The lean system as they imagined it
in the 50s and essentially what Toyota was saying is this we have a goal of
creating the highest quality product at the lowest cost and that's great. Every company has
that same goal. The interesting part here is that they want to build it in the
shortest lead time.
And what they mean by that is that we're only going to manufacture
the things that we know we need to manufacture right, think about it. We're always
moving from doubt to certainty. So if we know today that we need to
build a hundred cars, we are only going to manufacture the components
to assemble a hundred cars because we don't know if we're
going to build a hundred and first hundred, second, hundred and third car.
And producing the materials to create those cars. Beyond a
hundred storing that material transporting. It is
all waste, there's cost there and it's wasteful and we don't know if
we're ever going to recoup that cost. So let's only do what we
need to do, when we need to do it, where we need to
do it in the quantities that it needs to get done.
Now at the same time, we're ensuring that our process is as
efficient as it could be. And if it isn't, we stop the
process.
We re harmonize the process and we start again because it's
easier and cheaper to fix problems in production than it is
once the product has rolled off in their case the assembly line. Now, in the case
of Toyota, every Toyota assembly line employee to
this day has access to a cord, the andon cord where they
can pull that cord and stop the production line. If they see something
wrong, something's happening that they don't like
they stop the process.
In software engineering, this is akin to us saying this process is not
working. We're not communicating well or not getting good
feedback, we're not building the right product. Let's stop this process. Let's figure out what's
wrong and then let's re harmonize and start it again. And
as we do, let's only create the artifacts, the
assets, the meetings, the bureaucracy that
we need to ensure.
What we know we have to build today.
Because anything else is potentially wasteful and we don't want to spend that time doing it.
More recently, gentleman by the name of Eric Ries wrote a book called, The Lean Startup, where he takes
this approach and he and he applies it to the startup economy.
Eric says, the Lean Startup has a premise that every startup is a grand experiment.
Now, take that word startup and replace it with whatever it is that you're working on product feature
service, widget, whatever it is, you're working on
Startup as well.
And that it's a grand experiment and that experiment attempts to answer a question and the
question is not, can we build this?
Because you throw enough time money and people that are problem. You can build anything.
Instead, the question is, should we actually be building? This
is this something we should be doing, right? We're moving from doubt to certainty. We don't know
if the Trap is going to catch the raccoon. It may catch the dog. Should we be
building this?
And if we should be building this, can we build a business around this?
And what's interesting is that the experiments that you're running to learn the answers to these
questions are not hypothetical, they're not theoretical, they're the first
versions of the product.
They're the early the minimally viable versions of these products.
Now, all of this is in service of again, reducing waste and
more importantly. And perhaps, most importantly, not building things that
people don't want.
In my opinion, that's the greatest waste. That's a waste of your
personal time at work to waste of your team's time your
company's time and certainly of your customers time.
And so, you take these ideas of agile, lean Lean
Startup together, and you combine them with design, thinking
and design, principles, and user experience. And you get the idea
behind lean ux,
Lean ux is inspired by these ideas, Lean Startup and Agile, development theories,
and it's the practice of bringing the true nature of a product to
light faster. Remember, working software, over, comprehensive
documentation, show me how it works. How do we get there first
and do that in a collaborative? Cross-functional way working
together with design, product management, engineering QA,
marketing content, editorial,
focusing less
on creating documentation that describes, this experience
and focusing more on building a shared understanding amongst that cross
functional team,
Of the actual experience being designed. So as a team, we
can collectively understand what we're building. Why we're
building it how our customers are reacting to it and then we can
make more informed decisions as a team. Now look
most software projects start like this a team has gathered.
They're given a problem to solve or project to work on and everybody thinks they know the
answer, right off the bat and they make an assumption that their colleagues all have
the same
Same idea in their head.
When in reality, everyone has a slightly different world view about how to solve this
particular problem.
And so when we work on these collaborative, cross-functional teams and we employ the ideas behind lean
ux, we start to extract these ideas out of people's
heads very, very quickly in the lightest way possible in the
most efficient way possible, because anything else would be wasteful, right? This is the
lean principles are in here. And as soon as we can get these ideas out of people's heads, on a
Blackboard on a whiteboard and sketches on Post-it notes,
whatever works for that particular team, we start to see that we're not on the same page.
Not approaching the solution. The same way. We all have a slightly different idea of how to do this, but
there's value in those different opinions because you can start to
combine them and to collaborate and to build off of each other.
And as you start to do that,
everyone is weighing in on the solution, the approach, the challenges
product design engineering, and you're getting a broader buy-in for the
team's Direction and the solution that they're working towards,
and it starts to build this shared, understanding
shared Focus.
And then ultimately team alignment where everybody is on the same page.
They have a clear sense of the problem that were solving how we think we're going to
approach it. And what will determine success now? Yes, along the way
moving forward. There will be new learnings
But this is an opportunity to get that alignment up front at the
beginning and it's that shared understanding. That's the
currency of lean ux. That's what you're trading
for fix specification documents and long design review
meetings and and lengthy conversations about whether the button should be red or
should be blue or have rounded corners, or if we should use this API or that
API, it's that shared understanding that allows you to move
faster and more.
Efficiently. Now, I want to dig in a little bit of the concept of shared understanding
because it's critical to the success of any collaborative.
Cross-functional process with this. This is my
neighbor, I live next door to this gentleman
and I live on a main street in Suburban America.
and if you were to drive past my house,
And see this scene.
This would be a fairly typical scene in Suburban America,
a man and his dog in their yard,
with a leaf blower on his back, as he cleans the leaves off.
Of his grass. He probably wouldn't think twice about it because you have a
surface level understanding of this situation and it looks
pretty typical. Now, if you were to start building a shared,
understanding of the situation, and come live in my
house, next door to this gentleman,
You would learn a few things, you would learn that
my neighbor loves that leaf blower.
He loves that leaf blower, I think as much as he loves his children
and it starts to make you feel about him like this. There are there certain
days where you start to understand that he's out there
on a very regular basis, let's say daily, perhaps
hourly at times cleaning every blade of grass
and acorn and Twig off of his grass. And if you try to work from home, on a
particular day, it might inspire you to send some tweets out into
the world.
To share your frustration with the noise. That's coming from outside on an
hourly and regular basis. And so if you lived in my
house and experienced this with me, you would
understand. You have a better shared understanding more context around this
situation. Instead of that, surface-level drive-by,
Now, if you take that experience and you take it one level further and you actually lived in
his house with him, he would learn to
two more interesting facts. That would give you a much better understanding of the
situation. The first is that he's OCD. And that's, you know, that's his
thing and he's working through that and the second is that he
has an angled driveway.
So, the driveway for to his house angles down. And at the end of that driveway, there's
a great
And if that great gets clogged with leaves and twigs and rocks and
acorns, and excess grass clippings, then when it rains, or when the snow
melts, he gets water in his basement.
And he doesn't want water in his basement. And so he's obsessively out there every day.
Making sure that there's not a straight piece of natural, organic material, anywhere,
near that great. Now the point is that the
more you experience these situations together, the greater
understanding, you have of that situation,
and the more you do that together as a team, the less you have to communicate that through documentation and
writing
and that allows us to move faster and more efficiently and this is our
goal. Our goal is to move forward in a parallel path process where
development and design are moving Full Speed Ahead on the same
thing at the same time.
And that's what shared understanding gets you. And so the question
is always asked is how does this all fit in with the agile process, scrum, specifically with these
Cadence processes and I want to make sure that that's clear.
If we talk about hypothetical to week iterations and whether you work in one week or two week, three
week, whatever it is that are tied together by some kind of a theme project and
Epic.
Product feature, whatever it is the focus of this Workshop
is how to kick off this entire theme together
as a cross-functional team to build that shared understanding and
then how to maintain that momentum throughout the
iteration. So, if you've got a larger upfront
set of activities, how do you even pick
specific activities, to ensure that the momentum continues
through each iteration and
Critical is that you have cross-functional participation at the beginning
from day one and that development begins
on day one of Sprint one. So you're building all the shared
understanding and then together you're starting to build product on day. One of Sprint,
one.
And that's what this Workshop is teaching.