This document provides an overview of rapid product development using a continuous feature improvement approach. It begins by introducing Zach Beer and his experience in product development roles. It then discusses some quick disclaimers about terminology and assumptions. The document advocates for determining the narrowest feature slice that can add value, delivering it quickly for customer feedback, learning from each delivery, and repeating. It provides examples of how to choose the right feature slice and develop critical feedback loops from customers. The document acknowledges challenges but argues the approach ultimately makes development easier and teams happier. It analogizes the process to incremental car feature development.

1. Rapid Product
Development
STOP GUESSING AND START DELIVERING!
Zach Beer
Polaris Solutions

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!

4. I believe we can serve our customers
better.

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

18. I believe this process will make
developers happier.

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

24. I believe we can serve our customers
better.

26. So if the car was a software feature…

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!

31. Thanks for listening!