In my previous post, I talked about finding your “drumbeat” for building a product. Similar to the beat of a drum, the product development process needs to have a steady, predictable, and consistent tempo.

Being reactive is more about responding to challenges when they appear or strike and are in most cases triggered by external sources like customer preferences and requests. More often than not, being reactive will lead to everything but a steady, predictable, and consistent tempo. On the contrary, being reactive often creates chaos, delays projects, and increases costs. However, there might be a good reason you would like to add a reactive or responsive element to your product development process. The reasons might depend on the stage you are in (eg: trying to sign your first customers) and what type of business you operate in.

Note that I won’t talk about bugs in this post. Although bugs are probably the most common type of issue that requires you to be reactive, most software companies will have some kind of prioritization framework to classify bugs which drives how and when bugs should be tackled.

Downsides of Being Reactive

Generally speaking, being reactive when building software is not the best idea. There are many reasons for that but I will list a couple below:

• Being reactive means you have to switch contexts all the time and context switching heavily impacts productivity.
• Being reactive means you cannot plan or anticipate projects which can lead to delayed timelines, increased costs, and poor technical/implementation decisions.
• Being reactive means you cannot take the time to properly understand your user’s needs and jobs to be done which might lead to building something that only serves the few (or even worse only a single customer) than the many.
• Being reactive can be super tiring for the people involved. Having to constantly switch contexts and lack of focus can be energy draining.
• Being reactive means you are running behind the facts and cannot execute what you believe are the strategic initiatives you should really be working on.

Do You Need A Reactional Element?

We adapted Shape Up to drive our product development process. We have cycles of 6 weeks and you could argue that 6 weeks is not a lot of time you would have to wait before you can act on a new problem or idea.

But you need to take into account the time required to build (and release) it as well. So it is safe to say most projects that are not in the current cycle are always roughly between 3 and 12 weeks away from being shipped, depending on where you are in the current cycle. That is quite a big spread and sometimes time is money and getting something done now might move the needle for the company.

Additionally, not all projects or ideas are full-blown pitches that require weeks of work. You might want to do some smaller improvements to the product or would like to extend some functionality of features that already exist. Shape Up acknowledges that need and there are ways to address that like bundling these smaller improvements into a pitch or using the cooldown period for that. However, from my own experience, these types of pitches seldom get chosen and the cooldown period is often too crowded with other stuff that we want and have to do.

Team “Don’t F*** Up” and Team “Grow Quickly”

One day, somebody from the team forwarded me an email that really resonated with us. It was a newsletter from StartUp Core Strengths (Matt Lerner) describing how in the early days Wise (former Transferwise) was organized into 2 teams:

1. Team “Grow Quickly” (GQ)
2. Team “Don’t F***k Up” (DFU)

Team GQ requires a “hold my beer” mindset, needs to be able to react quickly, and has a higher risk appetite. Team DFU requires flawless execution and has a lower risk appetite.

We tried adapting the concept and came up with the following setup that we have been trying out for almost a full quarter:

• We split our engineering team in two: team DFU (leave alone) and team GQ (respond quickly)
• Team DFU focuses on strategic initiatives like features we want to build and problems/needs we want to solve. We use Shape Up (pitches, betting, …) to drive the product development process for this team. We do not allow the team to be interrupted or pulled away to do other things.
• Team GQ can do more reactive, ad-hoc work. Engineers in this team are really close to our customers. They can be creative, iterate quickly based on customer feedback, and focus on success.

We try to keep the initiatives in the GQ team rather small, if it cannot be done in max 2-3 days, then it should be a pitch and then it needs to go through the betting table.

Finding The Right Balance

In my opinion, adding a reactive element to your software development process can be useful in some cases but you really shouldn’t overdo it. We still want to aim for a consistent, predictable, and consistent “drumbeat” to ultimately deliver high-quality software that helps us reach our objectives and vision.

I am a quite pragmatic person and learned in the past couple of years that many things in life are often nuanced. That might be the same here with the proactive/agile vs reactive approach. Striking out one completely in favor of another sounds too extreme. It’s a bit of a ballpark figure but a 3:4 ratio seems acceptable, where you should really spend no more than 25% of your resources on being reactive.

Also keep in mind that team DFU and team GQ attract very different personalities and require a different mindset. So you might have to switch things up every now and then if you don’t have engineers that are comfortable with working in one of the teams. This is especially true for team GQ which in our case requires our engineers to be working really closely with our customers, think about solutions for problems customers throw at them, and are often also missionaries preaching and advocating our product and technology.

I am curious to learn how you think about adding a reactive element to your product development cycle and how you accommodate for it.