2. Why this guy?
• Ten years working in Chicago-based start-ups
• I’ve held nearly every role in a development team
• Developer
• Tech lead / manager
• Architect
• Product owner
• Scrum master
Most of all, though: Because I’ve lived it and know it works.
3. Some quick disclaimers…
We’re going to talk a lot about customers. Customers are people invested
in using your product. They could be internal or external.
We’re going to assume you’re building on an existing product. If you’re
starting from scratch, a lot of the same ideas apply, but you’ll want to
tweak them somewhat.
We’re going to talk about a process pattern that depends on a number of
other ideas. I’m not going to go into significant depth on any of those as
part of this presentation.
While I encourage you to do so, you don’t have to do all of these things.
Each of them has value even outside of the larger pattern.
I’m happy to discuss any of these in greater depth after the presentation!
6. How did this happen?
The product owner failed to understand the needs of the customer
Few opportunities to learn from the customer
Forced to take a stab in the dark
Manufacturing requires waterfall product
development.
7. What do you mean by “waterfall product
development”?
All requirements determined up
front
Little opportunity to respond to
changing information
Only one opportunity at delivery
8. Why is waterfall product
development
problematic?
Scopes constantly change
No customer feedback until the
project is complete
Sometimes the problem changes
during development
Any mistakes aren’t caught until the
end
9. Customers can’t help us directly
Customers are great at…
… pointing out pain points.
… giving lists of things they think they need.
… adapting to change.
Customers struggle with…
… thinking in limited scopes.
… prioritizing what’s most important.
… being open to change.
10. We don’t know what to build either
We crave positive feedback
We don’t want to tell the customer “no”
We think that we understand the customer better
than we do
Manufacturing culture tells us we must build the
whole thing at once
11. I believe we can learn from our
customers’ actions.
12. Continuous feature improvement!
1
Determine the narrowest vertical
slice that can add value to the
customer.
2
Deliver this slice as soon as
possible, event if the feature isn’t
“complete”.
3
Learn as much as possible from
each delivery.
4
Repeat!
13. Choose the right slice to deliver
How can I add value to the customer quickly?
Is this where the users spend most of their time?
How can I unblock other critical deliveries?
This is a significant technical challenge, is there a way to prove its value?
For example, think about a user management system…
14. User management requirements
Before narrow vertical slices
Add a page to our website which allows
administrators to view, add, and reset
passwords for existing users
After narrow vertical slices
Add a page to our website which allows users
to view existing users
Restrict access to the view users page to
administrators
Add ability to add users to the existing view
users page
Add ability to reset passwords to the view
users page
15. Develop critical
feedback loops
A/B testing can inform
critical (or trivial!) choices
Actively engage with users
about specific changes
Tracking tools help you see
which features users are
engaging with
Heat maps can show where
users are focused
Observing recorded user
interactions can point out
pain points
16. Creating this way feels difficult…
We’re culturally programmed toward the manufacturing model
We’re praised for our “good ideas”
We want our customers to be fully satisfied immediately
17. … but it’s actually easier!
You have to know less to get started
You learn details as you go along
Smaller mistakes are much easier to recover from
You can focus on the most important things
Customers focus on progress
19. Development is easier with feature
branching
What is feature branching?
Create a branch for each feature
Only merge completed features
Why is it helpful?
Developers can work in parallel
Collaboration is easier, since
developers can share branches
Branches can be tested before being
integrated
Releases only contain completed
features
20. Automated testing gives developers
confidence in releases
Create well-written unit tests
Choose critical behavior-driven tests
Manual test only the newest release items
21. Automated delivery makes reduces the
pain of releases
Run automated tests on each build
Automate deployment to test
environments
Automate release approval
Automate release deployment
22. Even positive change is difficult
Old practices die hard
Existing team members may need training
Developers might complain about writing “more code”
Introducing testing into legacy systems can be challenging
23. Eventually, teams never look back
The most common long term complaints I hear are:
“This story feels too big, can we break it up?”
“Who checked in a broken test? All our tests should pass.”
“Why does the release take so long now? Five minutes is
forever!”
“How soon can I push this to production?”
27. #1 Determine the narrowest vertical
slice that can add value to the
customer
We want to build toward a convertible top
We identify that switching to a two door model is a requirement for
introducing a convertible top
Theoretically, this could add value to the customer
It would also give us customer feedback
28. #2 Deliver this slice as soon as
possible, event if the feature isn’t
“complete”
Don’t develop the convertible mechanism, it’s expensive and it’s not
needed yet
Find the simplest way to achieve the two door model
Ensure the two door model works correctly before shipping
Deliver the two door model to customers as soon as is practical
29. #3 Learn as much as possible from
each delivery.
Only ship the two door model to a limited set of users
Preferably select users who demonstrated interest
Monitor these selected users carefully after delivery
Compare these selected users to other existing users, are they more
satisfied?
Gather real data about our test users compared to existing users
30. #4 Repeat!
Presumably, our comparison didn’t go so well!
Stop the development of the convertible, customers aren’t willing to
compromise on four vs two doors
How much time/energy/effort did we save by shortcutting the process?
Get started on the next most valuable slice!
Nissan Murano CrossCabriolet, released in late 2010
In May of 2012, of the 29.5M cars registered in California, only 107 were Murano CrossCabs.http://www.edmunds.com/industry-center/analysis/drive-by-numbers-who-buys-the-nissan-murano-crosscabriolet.html
http://www.autoblog.com/photos/dumbest-cars-all-time/#slide-3870821
Feedback forums are rampant with complaints and wild solutions without understanding of the challenges involved.
Apple and Google both roll out interface-changing platforms and people adapt quickly. If these companies asked for feedback, they’d be skewered.
http://www.magic-emoji.com/emoji/images/1113_emoji_iphone_angry_face.png
Things to mention:
Google Analytics or similar for tracking page usage
Button placement example of A/B testing
Sometimes outcomes are easy to track, sometimes they aren’t (purchasing, for example)
You don’t know the crazy things your users are trying until you watch them!
https://monetizepros.com/encyclopedia/heat-map/
Nissan Murano CrossCabriolet, released in late 2010
In May of 2012, of the 29.5M cars registered in California, only 107 were Murano CrossCabs.http://www.edmunds.com/industry-center/analysis/drive-by-numbers-who-buys-the-nissan-murano-crosscabriolet.html
http://www.autoblog.com/photos/dumbest-cars-all-time/#slide-3870821