Defining the HubSpot Development Process

One of the questions people ask about our product team is what software development process we use. Do you practice scrum? Are you an agile shop? Does HubSpot take a Kanban approach? Are you lean? (That last one feels a little personal, doesn’t it?) The answer is always: we don’t follow a process, we pretty much just solve for the customer. And every time, they roll their eyes. 

Our “no-process process” might not always be a crowd-pleaser, but it's really what works for our team. We’ve taken a ton of inspiration from people much smarter than we are to find an approach that sticks. Our biggest influence is Eric Reis’ Lean Startup model. Of course, we’re hardly a startup anymore. We found our core product market fit a long time ago; scale is the name of the game right now. So, we’re always iterating on our process and developing it as we go.

The best way to describe what this process looks like today is through an analogy. In my younger, leaner days I did a fair amount of sailing; I loved being out on the water and racing with just the power of the wind. Looking back, I see some strong parallels between sailing and how we build products at HubSpot.

The reality of sailing is that no matter how much you plan, measure, and study you can never truly know the conditions until you are actually on the water. The wind is different, the currents are different, and the waves are different than you had planned. Even your crew’s and your own physical and mental state is different than you had expected before stepping onto the boat. Water, wind and people are extraordinarily dynamic. But despite all of this, a good sailor can always get from point A to point B by using their instincts and instruments to find the right path.

Every one of our small dev teams has a goal, their own point B. We spend a ton of time defining how we’ll know when we get there because these goals are a combination of a high level “what” and “when”. The what could be something as big as “build a CRM that a sales rep would love” or “make our blog editing experience more writer-friendly”. For timing, “by INBOUND” (our big annual conference) or “before July” are typical targets. As long as we all have a clear, shared definition of success, each team has the autonomy to figure out the best solution for reaching point B.

Once we have a goal, the next step is to get out on the water. In our world, that means getting something in front of the customer as quickly as possible. Our instincts and instruments are qualitative and quantitative data from customers. Once we can get feedback on a product, app, or feature, we can learn and respond. Sometimes, that means we have to pivot and figure out a new route. Other times, there are no surprises and we can stay on course. That’s why we don’t believe in roadmaps and specs. They don’t allow teams to change direction based on the conditions on the water.

Similarly, we don’t do sprints. Teams are hellbent on getting to a point of learning as quickly as possible so that they can come up with a plan. But you can’t put a timer on finding the right solution. A particular effort could take a couple months, others could be a couple hours. We don’t let artificial boxing of time define when we tack or change courses.

This can make timelines and deadlines tricky. As I mentioned, we set very big, broad timelines for getting to point B and don’t define incremental deadlines for each team. It’s up to them to define milestones based on where they are. The beauty of this is that it helps teams get aggressive about not polishing the product endlessly. Done is better than perfect. Besides, there’s no such thing as perfect.

This is especially true when it comes to development processes. This sailing approach is allowing us to scale and solve for the customer everyday, but that doesn’t mean it’s perfect for everyone. Companies have to find the process that floats their boat based on their goals, conditions, and team. For organizations that just want to get going and ship faster, agile may make a lot of sense. (My partner in crime over here at HubSpot, Christopher O’Donnell, had a pretty interesting tweet storm a few months back sharing his thoughts on agile processes. Maybe if we bug him enough he’ll write a proper post on the topic.) 

Our process works because it fits into our ecosystem of product development. Small teams, high levels of autonomy, engineering ownership, and a mission of solving for the customer are all key ingredients that make the sailing approach work.

I guess “ship it” is a fairly appropriate mantra for us afterall.