Rapid Product DevelopmentSTOP GUESSING AND START DELIVERING!

Zach BeerPolaris Solutions

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.

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!

I believe we can serve our customers better.

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.

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

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

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.

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

I believe we can learn from our customers’ actions.

Continuous feature improvement!

1Determine the narrowest vertical slice that can add value to the customer.

2Deliver this slice as soon as possible, event if the feature isn’t “complete”.

3Learn as much as possible from each delivery.

4Repeat!

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…

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

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

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

… 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

I believe this process will make developers happier.

Development is easier with feature branching

What is feature branching? Create a branch for each feature Only merge completed featuresWhy 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

Automated testing gives developers confidence in releases

Create well-written unit tests Choose critical behavior-driven tests Manual test only the newest release items

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

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

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

I believe we can serve our customers better.

So if the car was a software feature…

#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

#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

#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

#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!

Thanks for listening!