Busting silos, the WHY of DevRev

This post discusses some of the challenges companies traditionally face throughout the product lifecycle and how this lead to the creation of DevRev to fix these problems.

Busting silos, the WHY of DevRev

Start With ‘WHY’

In order to understand the Why of DevRev, it’s essential to understand the history and lessons of the past.

When Nutanix was founded, we started with everyone co-located in the same room which was easy to keep everyone coordinated due to the benefit of locality. At the time it was just engineering and we were all on the same Jira system (yeah, I know). However, as we grew, we added new teams (e.g., support, marketing, sales), each bringing their own tools (e.g., support brought Zendesk, sales brought SFDC, marketing with Marketo). As these teams grew, we also became physically isolated (e.g., sales had their own office, same for marketing, etc.).

This led to the formation of data (knowledge) and organizational silos, which became exacerbated as we grew.

The following figure shows an example of what this looked like:

DevRev Platform

We felt the pain of engineering not having access to the support system and context from customer discussions. We felt the pain of product management not having all the context to define and prioritize clearly. We felt the pain of sales reps not having clarity on their customers’ tickets, engineering roadmaps, and the status of items relevant to them. We felt the pain of support not having access to information like customer details and the status of pipeline opportunities. Lastly, we felt the pain of having to ‘ask’ for access or context instead of natively having it in the context of the work.

Why not just give everyone access to everything? Cost All of these have per-seat licensing, so it was not fiscally possible.

Why not just build a ton of integrations to replicate all data everywhere? Opportunity Cost. Integrations take time and each of these would have to be done point-to-point which doesn’t scale and/or work when things change.

We pondered if this was just isolated to us, however, after many discussions with our peers and established corporations; we found it is something that is rampant across many organizations, big and small alike.

Perturbed by this inefficiency and understanding the impact this had on ourselves and others alike, we had enough and knew there had to be a better way, hence the beginnings of what led to DevRev.

To learn about why these silos can be detrimental to a business, check out Why Silos Must be Busted.

Starting From Zero

At our previous company (including our current), we went through all of the phases from the initial ideation of the product and founding of the company, its design, and prototyping, getting something working in the hands of customers and eventually scaling the product and company.

In retrospect, four core phases of this lifecycle, or fundamental tenants, became apparent:

  1. Build
  2. Operate
  3. Support
  4. Grow

At a high-level something similar to the following figure:

DevRev Platform

We challenged these in different scenarios. Did it work for products? What about companies? What about our people? In all cases, we found it to be relevant and an excellent framework to structure how we thought about things and guide our decision-making and execution.

More information about this lifecycle can be found HERE

The ‘WHAT’ of DevRev

We sought to re-imagine what people building, supporting, operating, and growing products needed. Could we be everything to everyone? No. But for the 80% we will do our best to fix things.

Here’s what we imagined:

  • A single platform replacing some systems, augmenting others
  • A platform that related everything back to product
  • Integrated with systems to gather events/context (e.g., monitoring alerts, git events, etc.)
  • A modern browser interface
  • Fully integratable with APIs (benefits for both headed and headless modes)

The following figure shows how we imagined and are building this:

DevRev Platform

Silos are bad for most businesses; this is not an unknown thing. However, by enabling everyone to have the same context, we can enable everyone to work in unison towards a common goal; driving a much more efficient and productive experience for all.

We understand this is a journey, and greenfield scenarios aside; some products may fit in some of these spots today. While we would love to displace all, the platform doesn’t require you to do so. For example, you may use us for build and support today in conjunction with Salesforce CRM.

In that vein, our goal isn’t to sell products. Instead, it is to enable people to build, operate, support and grow products more effectively.

essential