Building at the early stage

Before we started Linear, Jori and I built another company that was part of the Y Combinator’s Summer 2012 batch. There were a lot of lessons I learned from YC. However, one thing I wish I had understood better was what effective product development looks like.

Back then, we knew how to code, design and ship but we didn’t know how to prioritize effectively, set meaningful goals, or keep the momentum up week after week. While at the very beginning this is not that critical. It becomes more when you get to the stage of having a product and user to support. You need some structure to keep making meaningful progress and not going around in circles.

We learned some of this as we went through YC, and later over the years working in companies like Coinbase and Airbnb. I wish I had this understanding then and would have been able to focus more on the right things.

I often get questions from early-stage founders asking for tips and advice on how to run product development in the early stages. This is the basic model we use as well as some advice on how to think about product development in the early days.

—

P.S. We built Linear in part to make it easier for anyone to build products and give people a tool we wish we had when we were YC founders, one that was easy to use and encouraged good product development practices so we could spend more time shipping and talking to users, and less time figuring out how to manage our work.

Active YC companies get a year free of Linear. Find details on our YC deal page.

Execution in the early stage

As a new startup, you operate with a non-existing, or small user base, unfinished product, and limited understanding. In those early days, it’s better to aim to move fast as possible, try things out, learn and then fix and adjust. Momentum matters more than anything.

Moving fast doesn’t mean you shouldn’t have any structure or goals. The structure aims to keep up pace and momentum week after week, maintain the team’s health and avoid going in circles. You should keep these structures and tools lightweight as possible and make sure each of them has a purpose and it aligns on delivering value to the user.

Build with users

Much of the early startup process is about learning what your customers want. You should seek out users or potential users for feedback, iterate, and be flexible to meet the demands of your customers and the market.

Vision vs Feedback

However, your task as a founder is to find a balance between building toward your vision/intuition and building what the users want. Too vision-based products might miss user and market needs while too reactive products become Frankenstein creations without a clear purpose. You need to keep refining your product vision based on your user feedback.

Solve the problem not the feature

Understand that users will project their needs from the context or product they currently see, not the product that you’re trying to build. It’s common for users to ask for features you should add. Whenever they do, it’s important as a product builder that you ask them questions back. What is the use case? What is the problem they’re trying to solve with this feature or solution? How would their experience of the product be different if the problem was fixed?

By pivoting the conversation away from a feature request and toward explaining the problem they are trying to solve, you move the discussion towards the pain point. In this conversation, you’ll learn whether the problem is valuable to solve or nice to have. It also allows you to explore multiple solutions to the problem, and to choose the right one within the context of your broader vision.

Build for the right users

You may also talk to users who have a lot of feedback but who aren’t in your target demographic or aren’t it now. If you think you are building for things for early-stage startups, listening to an enterprise customer will likely set you on the wrong path and it’s unlikely that they will even become a customer.

Incorporate the feedback and let it refine your product, but don’t let user feedback alone dictate what you build. You can become too reactive to user feedback. This is why it’s good to have goals and roadmaps, that help you balance the needs of the users and the needs of the company.

Set useful goals

Startups move so fast that it’s normal not to know what you’re working on the next day let alone the next week. Goals are important to remind you what matters for the medium or long term success of the company. You might not feel like you have enough users or historical data to make decisions on what your goals should be. That’s normal and in those situations, create a goal that propels you forward in some measurable way.

In the early days, it can be hard to hit those goals when you start from zero. The way to think about it is to walk back from that goal, what is the path there. Path to 10 users starts with 1 user, which starts with having a product that someone can find and start using.

During YC your goal is to achieve meaningful traction by demo day. Your first meaningful goal getting there could be to find 10 users to use your product, then 100, then $1000 in MRR. Successful startups often start with something small, figure it out, and then scale. And remember, there is no limit to how fast you can grow.

Use a roadmap set the path

When you have some idea of which goals to tackle first, the next step is to figure out how. A product roadmap in a startup is a list of things you think you need to build to get where you need to be. Roadmaps are about setting direction and writing it down helps the team align on the direction. You should also realize you cannot do everything at once. The key is to think broadly but then only choose few things to do well and likely help with the goals.

In the first months of building Linear, we used monthly roadmaps. We’d brainstorm projects based on our goals and what we learned the month prior. We then selected 1–3 larger projects we saw most impactful towards our goals. This practice repeated over months helped ensure that we kept leveling up the product and didn’t get stuck only optimizing existing features. By only choosing a few larger projects, and not planning our time 100%, we left ourselves bandwidth to work on fixes and feature ideas from the user feedback.

We have a roadmap feature in Linear that you can use to build your roadmap but in the early stages, it can be as simple as one spreadsheet or document that lists the following.

• Project title
• Project description (at this stage you can have few paragraphs or bullet points to describe what do you think the project is for)
• Why are you building this? (rationale why is it’s needed, how it’s supporting your goals etc)
• The owner (who is responsible for building or driving this if there are multiple people)

Later, as the team grows or you feel that it’s necessary, you can expand these by writing brief 1-pagers to communicate the scope and details for the whole team.

Scope projects down

At the early stages, scope projects. Design projects so that they can be completed in 1–3 weeks with a team of 1–3 people. Smaller fixes or additions should take only hours or a day. Shorter projects force you to prioritize the most important feature set, create quick feedback loops with customers and get into the habit of shipping continuously. Smaller teams help you move faster and reduce the overhead. When you’re early in the product building stage, you don’t know enough to predict whether a project will be impactful or not so it’s better to avoid massive projects. If there is no way to scope down the project, then break it down into stages.

For example, we shipped the first versions of Cycles and Projects in the first couple of months of starting Linear. The MVP version of both of these features took us about two weeks to design and build. We shipped the early versions to ourselves and private beta users in the first week and started collecting user feedback immediately and fixing them in the following weeks. We’ve made a lot of improvements to Cycles and Projects since and both of them are now the major features of the product.

Ways to Prioritize

It’s really important to learn to prioritize and have a rationale why you prioritize something. You don’t have unlimited resources or time.

First, it’s helpful to think of new features as additive enablers or removing blockers. Enablers enable new functionality that usually makes the product more valuable or interesting. Blockers are gaps or friction that prevents a user/customer to use your product. (Note: You should try to understand if the problem is truly preventing someone from using the product or nice to have). You need to work on enablers and blockers to grow.

Secondly, it’s important to consider how timely something is. In the early stages, there are a lot of things you need to build eventually, but you should prioritize things that help you move the needle this week or month. You want to ask yourself if this is important to be done now or can it be done later. If you are successful with the idea, does it help your goals?

Example: At Linear, we started only supporting Google Logins since that was the fastest way to build authentication and then move on to other features. We knew that eventually, we would have to support pure email and other login methods. This lets us move faster to learn about other features without spending our time building different authentication methods.

Weekly product development cycles

Whether you have a product roadmap or not, get your team together to discuss and decide what specific tasks the team will tackle this week.

Often with co-founders or with the team, there can be a constant stream of exciting ideas or debates. Use this one product meeting for brainstorming and discussion and then decide what is most important this week and commit to delivering on the tasks. Then get to work. Brainstorming or debating every day can be distracting and prevent the team from making progress. In the end, only shipped features matter, half-built features or winning debates don’t help your users and therefore your company.

We always assign tasks in a cycle to a specific person. This makes it clear who is responsible for delivering the task, ideally, the person is the right person to solve it and it also makes it easy to see who is overcommitted or who has more bandwidth.

As we started getting users, we would start to add bugs to our cycles to maintain product quality. Startups often forget bugs, which if left unchecked, can create enough friction that slows down your growth.

During our first months, we set our cycles in Linear to be 1-week (which we recommend for YC or generally early for the early stage):

• On Mondays, discuss end decide what to do next. Assign responsibilities and get to work.
• During the week as additional ideas or feedback came up, we would take notes personally, share them on Slack or add related tasks to the backlog but not start working or spend time debating them. This lets us capture learnings but remain focused on the work we decided to do earlier.
• On Fridays, we would review the work done, what we learned from our work, or talking to users, and then try to wrap up any open tasks if possible. The following Monday, we would start the process over again.

Don’t get paralyzed

Building with momentum

You and your whole team should always try to take swift action and make progress each day. Instead of thinking or talking about doing something, you decide to do it or not to do it. Then you do it today instead of tomorrow and this week instead of next week.

There will be also weeks when you won’t necessarily know what is the most important thing to do or you are not sure what decision to make in the product. Don’t become paralyzed in those moments–find a way to act instead. Trust your intuition and do something that seems to make sense. Talk to more users. You’ll gain more clarity as more feedback rolls in. If you’ve designed your operations to move fast and learn, then you can correct or revert decisions.

Startups rarely die because they made too much progress or because of a single bad decision, but they do die when they move too slow or give up

Build in public

It might feel dangerous to show what you’re building but often it’s more useful. If anything, your competition might be discouraged by your speed and either forced to copy you or avoid copying you.

One way to build in public is to publish a changelog. It might seem silly to summarize your work in a changelog when you don’t have many users, but we think it’s helpful. For you and the team, it reminds you every week what happened and encourages you to ship constantly. For users, it shows the product is getting better. For investors, it shows progress. At times, when you feel things not moving as fast, you can look back at how much you achieved already.

There are other reasons why the changelog can be useful. Read more: Startups Write Changelogs

Launch and keep launching

People often think there needs to be a singular moment for launch. This doesn’t have to be the case and a lot of times many startups launch multiple times. It usually works better than having one massive launch. The problem with massive launches is that it takes time to prepare and they are riskier. There is also an increased risk that the launch won’t work and all the work is wasted. By launching multiple times, you are building your story and brand over time and compounding the interested people have. Each launch builds more following, which then helps your future launches.

Secondly, in the first months or years, your product is likely not a fit for everyone. It’s better to launch early, start getting users and momentum, than trying to wait for that perfect moment.

Similar to changelogs, launching keeps reminding the market about the fact your company exists and you’re making progress.

Example: With Linear, we launched by announced the company before we had the product built. We launched when we raised seed funding and evolved the product. We launched when we opened the product for everyone and added pricing. We launched when we did a Series A and evolved the product. Each of the launches had reached more people and generated more customers than the previous ones. Had we only launched once, it would have taken us 1.5 years to get to the state and we wouldn’t have learned as much and would have as many customers as we have today.

Try Linear

While can use any tools or use no tool at all, we did create Linear to help startup teams to build momentum. Many YC and other successful startups use Linear today to manage cycles, organize roadmaps, and have that lightweight structure you need: linear.app

Active YC companies get the Linear Standard Plan free for a year. Visit the YC deals page to activate it.