The document discusses the failure of Plancast, a social sharing platform for event planning, highlighting the pitfalls of relying on vanity metrics and misunderstanding user engagement. It emphasizes the importance of continuous improvement through lean UX and agile methodologies, advocating for a collaborative approach in product development. The document ultimately calls for a shift from traditional product management to a more iterative, user-centered process that prioritizes real experiences and team alignment.

1. Lean UX Workshop I

2. Lean UX
Agility through cross-functional collaboration
Workshop
Chris Barklem
Lean UX Labs & Just UX

3. Looking at failure
The story of Plancast.
The founder, Mark Hendrickson, was a writer and web developer at Techcrunch, he
left and started Plancast naming himself "Product designer and developer".
http://techcrunch.com/2012/01/22/post-mortem-for-plancast/

4. Looking at failure
Here is his discription of what happened..
Plancast was to provide a really easy way for people to take whatever interesting
plans they had in their calendars and share them openly with friends, with the
rationale that greater social transparency for this particular type of personal
information would facilitate serendipitous get-togethers and enable a greater
awareness of relevant events.
Personally, I figured that knowing more about the events my friends and peers were
attending would lead to a more fulfilling social and professional life because I could
join them or at least learn about how they spent their time around town.
Along the way my team built a minimum viable product, launched from obscurity
on TechCrunch, raised a seed round of funding from local venture capitalists and
angel investors, and worked like mad to translate our initial success into long-term
growth, engagement and monetization.

5. Looking at failure
But..
Alas, our efforts began to stall after several months post-launch, and we were never
able to scale beyond a small early adopter community and into critical, mainstream
usage. While the initial launch and traction proved extremely exciting, it misled us
into believing there was a larger market ready to adopt our product. Over the
subsequent year and a half, we struggled to refine the product’s purpose and
bolster its central value proposition with better functionality and design, but we
were ultimately unable to make it work (with user registration growth and
engagement being our two main high-level metrics).

6. Looking at failure
"While the initial launch and traction proved
extremely exciting, it misled us into believing there
was a larger market ready to adopt our product.”
They did not look at :
• who where these people?
• what were their intentions?

7. Looking at failure
“100,000 have registered and over 230,000 people
visit each month.”
This is called a vanity metrix.
They are called that because they make you feel good about yourself. But they don't
tell you how your product is performing. If its working well, or if its working poorly.
Out of these 100,000 people, how many have actually shared a plan?
How many people have followed a user, how many return a second time, a third
time, a second or a third month. These numbers don't tell you that, they make you
feel good, but they don't tell you if your seeing any traction for your product.
“This leads to a false sense of success and a false sense of market fit.”

8. Is there a better way?
Yes!

9. The old fashioned way
Normally called the waterfall method
Design >
Requirements >
Development >
Support / Learn >

10. Software is continuous
• Your product evolves from doubt to certainty.
• It never stops evolving.
• We are no longer delivering a finished product, instead we deliver a
continuous stream of incremental improvements.

11. Software is continuous
11.6 seconds
• Amazon pushes new code to production every 11.6 seconds. Tests the outcome
produced by the change, if needs be rolls back the changes.
• Amazon pushes code, designed to test an outcome, before committing to a
solution.

12. No more “Model Years”
• No big changes with a finished product mentality
• No cramming in features
• No thinking about what features we can sell to the
user
Instead
Design a continues learning loop

13. The cutting edge
• Agile software development
• Lean Startup
• Lean

14. Agile software development
• 17 software developers, got together in 2000 with their frustrations.
• They were continuously missing deadlines, not meeting customer
expectations and continuously negotiating contracts as the project
evolved.

15. Manifesto for Agile Software Development
1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan
The men valued the things on the left more then the things on the right. This is not
saying they did not value things on the right, just not as much as things on the left.
They stated that they did not know upfront all the details, that over time as the
project evolved, so the plan needed to change as new information materializes.

16. Whats missing from Agile?
User experience, Design and Product Management
were never factored in during Agile’s inception.

17. What is Lean?
1. We are always moving from doubt to certainty
2. We are always moving in small steps towards certainty out of doubt
This was developed by Taiichi Ohno and his team in the 1950’s. Its
called the Toyota Production System. They could not compete with the
Americas on scale. So they decided to compete by removing all waste
from the system.

18. What is Lean?
http://www.ltech.eu/clients/casestudy_toyota3

19. Lean Startup
Developed by Eric Ries
Every startup is a grand
experiment. It intends to answer a
question. Should we be actually
building this?
• ELIMINATE UNCERTAINTY
• WORK SMARTER NOT HARDER
• DEVELOP AN MVP
• VALIDATED LEARNING
http://theleanstartup.com/principles

20. Be Lean
Reduce waste
Don’t build things people don’t want

21. Combine all the good
So if you combine all the good from Agile, Lean and Lean Startup you
will get the inspiration which lead to Lean UX
“Inspired by Lean Startup and Agile Development theories, it’s the
practice of bringing the true nature of a product to light faster, in a
collaborative, cross-functional way with less emphasis on deliverables
and greater focus on a shared understanding of the actual experience
being designed.”
– Jeff Gothelf

22. We start, thinking we all see things the same

23. Visualizing out ideas reveals inconsistencies
Between designers, developers, product owners, experts, marketers and customers.

24. Regular discussion leads to iteration
With each iteration leading to a broader understanding

25. Ultimately leading to a shared understanding
And team alignment (including your customers)

26. Working together grows understanding
The more you work collaboratively as a team, the more your shared
understanding of the problems and solutions evolve.
Ultimately you are all able to work effectively on parallel paths with the
same clear understanding of where your going, why your going and
how together you are going to achieve it.

27. How will this fit in with Agile?
Use a cadenced Scrum process

28. End of theory, start of practice.