Introduction

This is a new series where I’m documenting the entire process of building my 6th SaaS product.

It’s an app that connects all the knowledge in your team and makes it super accessible:

It’s called Horizontal

Positioning

The goal of product positioning is to answer these three questions:

What is it?
Who is it for?
Why is it better?

Who is it for

Determining your ideal customer profile has three steps:

Workflows
Competitive alternatives
Problems
Demographics

Workflows

It’s easy to say something like: “my app is for developers”

But what kind of developer? Is your app for every developer on Earth? I doubt that. Not even git is for every developer. It’s only for developers who want to use source control.

At the end of the day, all B2B software is workflow software. There’s a workflow that needs to be digitized, modernized, sped up, simplified, etc.

If a company doesn’t do lots of outbound communication, then your awesome CRM is not that valuable to them.

If a team doesn’t use tasks, docs, and communication, Horizontal is no good for them. There’s no workflow to make better.

The positioning of your product should be rooted in the workflow it solves.

Workflows come in different flavors and sizes. It can be as small as “scheduling a meeting” or as large as “generating new leads for the company.” The latter is a multi-team process that can require thousands of dollars, while “scheduling a meeting” can be as simple as me clicking in my calendar.

Now, let’s think about engineering team workflows. What is the purpose of a developer team from a business perspective? To develop a product. Which is a huge workflow that contains hundreds of smaller ones.

If we go further down, I think there are 3 high-level workflows:

Develop new features
Deploy code
Improve the system

We develop new features based on input from the product team, we deploy code to production, and then improve the system by fixing bugs, performance optimization, etc.

(box sizes are not proportional to the time spent in each workflow)

To develop new features, we get input from the product/business team in terms of feature requests, ideas, requirements from clients, etc. We transform them into our own language, involving workflows such as:

Writing technical specs
Creating tasks
Estimating
Managing tasks and milestones
Managing domain knowledge

These are much smaller and more concrete workflows. It’s now much easier to find existing software to solve a given workflow, for example:

Writing technical specs → Google Drive
Managing tasks and milestones → Trello
Managing domain knowledge → Confluence

Once the team has a conceptual and technical understanding of the new features, we can start writing code. Which is another workflow with many smaller ones in it, for example:

Writing code
Managing versions
Managing technical knowledge (coding guidelines, architectural decisions, etc)

Once again, we can assign products for each step:

Writing code → JetBrains
Managing versions → git
Managing technical knowledge → Confluence

So far, we have the following diagram:

Without going into further detail, the rest can be completed like this:

It’s not perfect, it doesn’t contain everything about our craft, but it’s good for demonstration purposes.

In my experience, there are three kinds of products.

Vertically owns an entire workflow

Think about AWS:

They own everything in the “Deploy code” space. CI, CD, databases, servers, clusters, scaling. They offer even more stuff.

Horizontally owns multiple workflows

It’s really hard to find a product that does this in the engineering space, so this example is flawed, but think about Jira and Atlassian products for a minute:

Okay, you cannot run k8s clusters with Atlassian, I know, but they try to support every workflow in this space. For example, you can build pipelines in BitBucket, you can integrate bug tracking software, etc.

In business applications, it’s easier to find these kinds of products. Think about HubSpot or Salesforce. They are a complete operating system for marketing/sales/business development teams. Multiple departments, multiple workflows.

Owning little pieces of multiple workflows

The third example is Google Drive and Confluence:

Drive doesn’t want to run an entire workflow in your team. They support each step by providing a space to create and store documents. By “managing knowledge,” I mean things like:

Gathering information from a product manager
Documenting existing features
Designing new features
Designing your infra
etc

Other examples from this category:

Slack
Calendly

The first step in positioning is to place your product on this diagram.

Your positioning on this scale determines a few things:

ACV means Average Customer Value. The more you do for a business, the more you can charge for it. For Google Drive, it would be hard to justify a $660/user price point. HubSpot, on the other hand, can pull this off (5 seats for $3,300):

Sales-led growth means you have a sales team, and you mainly sell your software by having sales meetings with potential customers. Each customer has a custom contract, etc. For example, the main CTA on HubSpot’s pricing page is “Talk to Sales.” You cannot buy their software without talking to a salesperson (I guess). Glean is so enterprise, they don’t even have pricing on their public page. You need to talk to a guy to see prices.
Product-led growth means the product itself is the primary driver of customer acquisition. Users can sign up, explore, and upgrade without needing direct sales intervention. It doesn’t mean “the product is so good it’s gonna sell itself.” It means your main objective is to attract visitors to your landing page who become users and customers over time.

Horizontal is going to be a search platform.

It integrates Drive, Jira, Slack, etc, and provides one awesome place where you can find anything in your team’s knowledge. It’s going to understand the relation between a PR and a Slack conversation, etc.

My positioning looks like this:

From a workflow perspective, the best customer for Horizontal is someone who works with a lot of information in engineering teams.

Competitive alternative

Who is your main competitor?

Don’t just think about direct competitors. Often, a competitor of a product is a product from a different category.

For example:

Slack’s main competitor was email. Not another IM application.
Loom’s competitor was meetings

You have to think about how your potential customers are solving the problem right now.

There are some direct competitors for Horizontal, for example:

Glean
GoSearch

However, they are so enterprise that I don’t know a single person in my life who uses them. I have only worked with startups and small companies in my entire life.

I know lots of people who are going crazy finding and managing information in Slack, Drive, Jira, GitHub, etc. But I don’t know anyone who uses Glean.

So, Horizontal will be positioned as an alternative to “manually searching through Drive, Slack, Jira, Confluence, Email”

Problem

The third leg of product positioning is a specific problem that you are solving, which is experienced by customers, and they are aware of it.

The main pain points experienced by potential customers of Horizontal:

Not remembering where we talked about a specific problem/solution. Was it a GitHub PR comment, a Slack conversation, a comment on a Google Doc, a conversation in Slack, an email, or a meeting?
Not remembering the history of things. For example, we developed a feature in a certain way, but why? Why did we originally choose that way?
Not being able to connect things. For example, an issue originates from an email, but you lose that context.
The awful search bar on Google Drive
Disorganized and hard-to-follow folder structures on Google Drive
Too many Slack channels and threads
Too many Jira issues
Bad onboarding experience
etc

List all those pain points for your product/customers. This will be important later.

There can be two kinds of pain points:

A problem with a competitive product
A problem in the workflow itself

For example, ClickUp created an entire campaign around how bad Jira is. They called it The firing of Jira. They positioned themselves as the solution for Jira.

On the other hand, Horizontal will be positioned against manually searching through 5+ data sources.

Demographics

The last step is to determine the demographics of your ideal customers.

With Horizontal, I will target smaller companies and early-stage startups. Mainly for three reasons:

They don’t like overcomplicated enterprise software. They don’t like bureaucracy.
I can reach them through my audience
I have only experience working in smaller companies

Also, I think they are underserved in this market. Everyone focuses on enterprises.

My ideal target is the lead developer or CTO of those smaller engineering teams.

To summarize everything in a table: