Great software teams don't release in phases

The dangers of 'Phase 1's, MVPs and PoCs

Have you ever seen a similar roadmap?

This is the most common interpretation of having an ‘agile’, ‘lean’, ‘startup-like’ (pick your favorite buzzword) mentality.

On the surface, it sounds legit. Instead of releasing a huge feature all at once, you break it down into smaller parts. You understand what is the minimum viable product, and what can be done later.

Each sprint you need to release something, right? That’s the meaning of being agile!

Wrong.

You decide in advance how that feature will be developed, and you will be forever biased to follow that roadmap.

So when you get some customer feedback, you hear what you want to hear. Any negative signal about the future phases will be ignored, and positive ones will be clung to.

When you have a well-defined ‘phase 2’ in the roadmap, it means that you already decided. The chances you will stop after phase 1 are very small. The same problem exists with MVPs and PoCs - if a ‘PoC with a first customer’ is followed in the roadmap by ‘Feature Y improvements’, you fall into the same trap.

The point of being agile, lean, fast - is not only to release in smaller chunks. It is also to:

1. Be able to change your mind.

2. Be willing to throw away your roadmap.

Otherwise, you end up like this:

Source: this LinkedIn post

5 questions engineering leaders should continuously ask

Up to now, we have covered what is considered a ‘Product Manager’s domain’.

I want you to challenge that assumption.

When you are consulted about a roadmap for your team, ask those questions, from the easiest to the hardest:

1. How are we going to measure this feature?

A basic question that is often overlooked. Is it based on usage metrics? Will there be customer interviews? What metrics interest us?

Sometimes engineering work will be needed to actually track complex metrics.

2. How is the success of phase 1 / MVP / PoC defined?

Ok, so we have the metric we hope to improve. What should be the effect of the first phase?

3. What will happen if the criteria are not reached?

Here the hard questions start.

If our goal is to improve retention by 1%, and we improved it by 0.8%. What will happen? Usually, the answer is ‘nothing’… Which begs the question of why the goal is set up in the first place.

4. How will the scope for phase 2 be decided?

How will feedback from the first phase be incorporated into the second one? Will we just do minor fixes, or will we consider a complete priority change?

5. What can make us decide not to continue with this feature?

The toughest question. I would be surprised if you’ll get an answer in most companies.

Remember that it may be ok to answer ‘‘nothing” to the last question! Could be the CEO is sure about that feature, and is willing to spend time on it no matter what the customers say. Sometimes the customers don’t know what they want.

The important part is to know WHY that’s the decision, and be able to explain it to your people.

Helping your team adapt the ‘pivoting mindset’

Let’s assume we live in a perfect world, where all the above advice is implemented. You finished the first phase, and the decision is taken to not continue.

Your engineers will be very frustrated…

It will mean that big parts of the code they write will be thrown away.

I’ve never met an engineer who wasn’t upset when their work was not needed. It makes them feel as if bad decisions are made, and they might lose trust in the company.

Before I’ll cover my tips, let me share a story:

In the late 1950s, Honda wanted to start selling motorcycles in the US and decided to compete with Harley-Davidson by selling large, powerful bikes. It didn’t go very well - the bikes had problems, and people weren’t buying them.

In their office, Honda employees used small 50cc Super Cub bikes (that were not meant to be sold) to run errands and get around. One day, a frustrated employee decided to take a break. He grabbed one of the small bikes and rode it into the hills to vent a bit. He had so much fun that he shared the experience with his colleagues.

Soon, more employees started using these small bikes for short rides and adventures. People noticed and started asking where they could buy them for themselves.

Honda saw this unexpected interest and decided to bring more of the small bikes from Japan to sell in America, and they quickly became very popular.

Thanks to this unexpected turn of events, Honda changed its strategy. They focused on selling the small Super Cub bikes, which became a huge success. This pivot helped Honda become a major player in the motorcycle market.

This story is from ‘How Will You Measure Your Life’ by Clay Christensen, I covered additional takeaways from the book here.

Imagine what the team behind the powerful bikes felt. Unlike software engineers, some of them couldn’t just move on to the next feature and were probably fired.

Many companies, would have fought to the death for the big bikes. It takes guts, and the right mindset, to be able to pivot.

Now back to software. There are companies that did hugely successful pivots, such as Slack, Twitch, and Paypal. The same mindset that allowed those founders to make the decision is needed in every company, to be able to do a roadmap-pivot.

You have to communicate to your team that a decision to stop working on a feature is one of the best signs of a strong product culture! It means the decision-makers are listening to feedback, and considering carefully what’s the best way forward.

If you complain about those decisions yourself, your team (and the company) has no chance.

Be aware of the other extreme

While much rarer, there are cases where the decisions are changed too often. Your engineers are interrupted in the middle of the sprint to work on the new pet-project of the CEO.

In ‘It Doesn’t Have to be Crazy at Work’ (which I covered here), Jason Fried shares how they work at basecamp:

…It's why we've never committed to a product roadmap. It's not because we have a secret one in the back of some smoky room we don't want to share, but because one doesn't actually exist. We honestly don't know what we'll be working on in a year, so why act like we do?

We work on projects for six weeks at a time, then we take two weeks off from scheduled work to roam and decompress.

6 weeks sounds like a reasonable amount of time - but it may differ from company to company. If you are a pure SaaS in the early stages, maybe 6 weeks is too much. If you work on hardware, 6 weeks is definitely not enough.

Experiment and find what works.

Final words

I read somewhere that an anti-pattern is just an overused pattern.

I definitely don’t have the answers - as I moved to the Director of Engineering role, I started to go deeper into the Product Management job, and I have my (sometimes strong) opinions.

Maybe for some companies, a detailed roadmap with phases is the right fit.

Lenny Rachitsky

and

Ben Erez

wrote a great article in the defense of feature team product managers, and they cover that aspect.

The important part is to have a curious mindset, and constantly trying to improve the way you work.

What I enjoyed reading this week:

1. Why Your Product Transformation Will Fail by

   John Cutler

2. How a 6 months partnership has ended by

   Orel Zilberman
   (this one is about a partnership with myself :)

3. Communicate Effectively To Get What You Want by

   John Crickett