When Vibe Driven Development Stops Being Enough

Eric Adams

Consulting Software Engineer, Engineering Executive at Studio Connect, LLC


The Problem: What to build next

Several years ago, the company I worked for ran into a problem. We had been working on iterations of the same software product since 2014; when I joined in 2016, we were growing a base of clients, while continuing to add value to our core features. There was still a lot of 'green' in the greenfield aspect of our project, and we had a strong idea of the direction we were heading. Our client base continued to grow, and we saw healthy revenue growth and retention as well. Then we started to notice a change.

We were still signing new clients, but their feature requests started becoming increasingly divergent from what we considered our core value proposition. One client wanted better reports. Another wanted content moderation. Another wanted integrations with BI applications. The list went on. All of these requests could be framed as reasonable once they were described in the use case of the organization. But did they make sense for everyone? Were they worth our time? Were they important to us? Could they be important to our long-term success?

"How could we know the answer to any of these questions?"

A Possible Solution: Vibe Driven Development

The question of prioritization in software product development is certainly not a new one. There are often competing interests in the lifecycle of a product, and a plenitude of inputs into what might be possible. We'll come back to this in a bit!

In a recent article, Robin Rendle used the term Vibe Driven Development to propose a simple idea: Organizations that regularly use their products will have a good sense of what is lacking, and this sense trumps any analytics or user behavior tracking you may already be using. It is an intuitive article describing an intuitive process, and is also entertaining for any person working on the product side of software development. I highly recommend it.

The Vibe Problem

Vibe Driven Development describes a process that requires organizational buy-in. If your development priorities are governed by the vibes of your employees that are using your software, then you had better be darn sure they're using it. It also relies on several variables that I would posit have issues at scale. Let's dive into some of these.

The size of the company

One of the points Robin Rendle makes in the argument is that smaller orgs will naturally follow vibe driven development principles:

"Whilst smaller orgs typically aren't run by the numbers, they're so focused on the product because they have to."

This is definitely true—smaller orgs will tend to be more nimble in their development, and will work more tightly connected to their products and users. The inverse is also true—larger orgs will tend to interact and develop with less direct product attachment, as there are more interested parties, and therefore more layers of conversation and approval required. While a small company may have a team of 10 developers all working on the same product, a large company will have 10 developers working on a single feature within the product. The shift in context here has a significant impact on both product usage and prioritization, thereby impacting vibe driven development.

When it comes to sales, smaller organizations are able to quickly communicate between sales and product, and development can rapidly respond to market requests. In larger orgs, developers are not likely to have a direct connection (if any) to sales; their efforts occur downstream of the sales process, and part of the vibe is lost.

The number of clients

When I started at my last company in 2016, we had a handful of active clients. Developers were first-line support, and support was manageable. We often knew the "regulars" that would request support, and we had good rapport with them. They effectively became a part of our development strategy - these power users knew the pain points in the software, and helped surface problem areas quickly. We could both fix their issues and stay focused on planned feature refinement because these two inputs didn't often diverge.

As we continued to grow clients, two things happened; the number of support requests grew, and the types of questions varied more than before. This made sense to us—more clients will mean more users, and more users means more input sources with more variation. This is a good problem to have! However, we found ourselves balancing these requests with our planned development, and starting to ask more questions about what we should prioritize. In effect, the vibe didn't matter as much.

The age of the product / market changes

Every developer and every product manager loves the greenfield project. Why wouldn't we? They provide an opportunity for us to utilize our creative skills, building a product in our image. When we're building a new product, or perhaps a secondary product for an existing company, we get to live in the vibes. We are building everything, from the smallest link to the largest feature. It is all part of the same process, and it is wonderful. You know what makes this process even more wonderful? When PEOPLE start using your product. Consider it "vibe validation", a signal that you are attuned to your market.

Unless you happen to be the only product in your space in the market (you're probably not), you will likely need to provide unique value to your clients. However, once your product has been around for a few years, you may find that your unique value is not as unique as it used to be. You may find that competitors in your space have unique features that you are being asked to replicate.

You may also find that the market is not as well aligned to your product as it once was. For example, let's say you made a desktop application for setting up appointments for insurance claims adjusters. An adjuster can book their appointments, add client information such as name, address, policy info, and so on. Things are looking great - until a new mobile app is released by a competitor. It allows them to book appointments directly from their contacts, use maps to direct them to a location, and sends automated messages for claims follow-up information to their clients. These are all unique value propositions that revolve around the mobile nature of a claims adjuster's daily work. Your product may do everything it promised - and do it well - but you are now being outsold, and churn has increased.

What does this all mean?

All of these issues a company will encounter that alter the vibe-driven development paradigm are what I'd simply refer to as growth factors. As growth factors increase, you will see increased inputs into your product development lifecycle, and decreased ability to ride the vibe-wave.

Graph showing development effort changes over time

What I am attempting to visualize here is a reality all software companies that build and sell a product will have to come to terms with. As your company grows, you must achieve a balance of what development is required to follow your company's vision with what is required to maintain a stable software company.

How do we manage these inputs?

Describing all the different ways to prioritize a product roadmap goes well beyond the scope of a single article! I personally believe the decisions on how an organization should prioritize their roadmap will depend on the type of product culture they are. In my experience, I've found that the RICE Scoring Model is a great way to try and eliminate bias from the decision-making process, and surface truly impactful features. If you've found success with other models, I'd love to hear more about them!

In Conclusion

Vibe driven development is a great way to describe the process of a software company that is well-attuned to their product and their market. I absolutely think it describes a product culture that all organizations should strive to follow! I would also say that vibe driven development will objectively falter at some point, and you will need to arrange and prioritize your competing signals for the best success.

Additional Resources:

Be notified about next articles from Eric Adams

Eric Adams

Consulting Software Engineer, Engineering Executive at Studio Connect, LLC

Organizational StrategyDecision MakingCulture DevelopmentEngineering ManagementPerformance MetricsLeadership TrainingFeedback TechniquesSoftware DevelopmentCareer GrowthCareer Progression

Connect and Learn with the Best Eng Leaders

We will send you a weekly newsletter with new mentors, circles, peer groups, content, webinars,bounties and free events.


HomeCircles1-on-1 MentorshipBounties

© 2024 Plato. All rights reserved

LoginSign up