Linear [lin-ee-er]
adjective.
: progressing logically from step to step; having a regular sequence of stages.
: involving measurement in one dimension only; pertaining to length.
: of, consisting of, or using lines.
Quick Recap:
Stay in touch w/ Friends
We are building a simple v0.1 of BetterFriend app by using WhatsApp Chatbot to remind people their loved one’s birthday with AI.
Building Software Products
Some say Product Managers are the master of none, others describe them as mini-CEOs. Regardless of how you view them, positively or negatively, we have to admit that making great software has become so complex over the years, with many components glued together. We need someone to glue them together or they often fall apart.
I’ve never been formally trained as a Product Manager at a big company - for better or worse. The role is quite different from a big company versus small. At a giant corporation like Microsoft, you could be in charge of only 1 single button that goes into Microsoft Excel that billions of people use every day. At a startup, you are in charge of the entire product end to end from branding, marketing, launch plan, UI / UX, tech stack, user feedback, you name it.
In this case, no need to for me unlearn bad habits. My advantage is that I’m learning this with the best practices for the very first time. And I found a world-class teacher:
Linear - the behind-the-scenes software that top software firms including OpenAI & Perplexity use for product development & project management.
https://linear.app/customers/openai
https://linear.app/customers/cashapp
Opinionated Software
SO many project management tools exist in this world: Jira, Trello, Clickup, Monday, Airtable, Notion. Too many. No one knows what to use.
I’m amazed by Linear which was only founded in 2019 to overtake some of these long-standing options to be the preferred tool for the best of the best. One company cannot use more than one project management tool - they must be 100 times better for them to overtake the industry giants from behind. I’m sold.
I got to work. One line in their onboarding “method” doc grabbed my attention:
Purpose-built
Productivity software needs to be designed for purpose. It's the only way the product can truly do the heavy lifting. Flexible software lets everyone invent their own workflows, which eventually creates chaos as teams scale.
The software has a fairly steep learning curve, on purpose. They made the software based on the best product management principles that they have learned themselves and they test the product with their own development process. For a newbie like me, this is amazing - It’s like the software is holding my hand to walk me through how to learn Product Management.
I found many of the principles that they laid out to be helpful not only for learning how to use their product, but also applies to building any product in general. Here are a few that stood out:
Meaningful direction
Even if your daily schedule is filled with smaller tasks, it's important to understand and remind everyone of the purpose and long-term goals of your work. Milestones, projects, and initiatives are all essential to consider when you plan your weekly schedules.
Say no to busy work
Your tools should not make you the designer and maintainer of them. A tool should work for you, not the other way around. Remove or automate "work around work", so you can focus on what really matters.
Aim for clarity
Don’t invent terms if possible, as these can confuse and have different meanings in different teams. Projects should be called projects.
Simple first, then powerful
Teams have different needs depending on their size. A tool should be simple to get started with and grow more powerful as you scale.
Decide and move on
There isn't always a best answer. Sometimes the most important thing is to make a decision, and move on.
These are principles that are timeless and I will often come back and read them again and again to remind myself.
Another part that captured my attention is the n-week cycle practice.
Cycles create a healthy routine and focus teams on what needs to happen next. 2-week cycles are the most common in software building. They're short enough to not lose sight of other priorities, but long enough to build significant features. Cycles should feel reasonable. Don't overload cycles with tasks and let unfinished items move to the next cycle automatically.
At the early stages, it's especially important to 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. They also get you into the habit of shipping continuously, which creates quick feedback loops with customers. Smaller teams help you move faster and reduce the management and communication 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.
Every founder / anyone who’s building anything should really follow this cycle process. Without the short cycles, we lose prioritization.
A core part of Linear is built around “Issues”. They want it to replace everything. In their own words:
User stories evolved over twenty years ago as a way to communicate what a customer wanted into product requirements that a software team could deliver. Fast forward to today and a lot of things have changed about how we build software. Customers are tech-savvy enough to articulate basic product requirements. We’ve developed standards for common features such as shopping carts, todo lists, and notifications so there is no need to explain how they should work. The best product and engineering teams understand their users deeply and are familiar with how their product should work.
Write clear, simple issues that describe tasks in plain language. Write your own issues. Discuss the user experience at the product and feature level, not the task level. Instead of spending time creating user stories, spend it talking to users and thinking through features before building them.
An issue should describe a task with a clear, defined outcome. This could be a piece of code, design, document, or action to be taken. If it’s not a task, then it doesn’t belong in the issue tracker. Maybe it’s a project idea that needs to be fleshed out in a document or conversation or a larger feature that should be broken down into smaller, tangible pieces of work.
It’s amazing to see them taking risk by standing firm on their belief - “user stories are obsolete” basically says everyone who’s still doing it is stupid. This is probably the most controversial statement that I’ve seen in a SOFTWARE.
I won’t go into the details of how they structure their flow of issues / projects / initiatives - this is best to learn here: Projects & Initiatives
What a luxury to be learning software development & product management in this age. We can skip all the bad habits and go to the best practices. I can see how the younger ones are learning faster than ever before with these new tools that are available for free.
Free account - anyone can sign up here:
I’ll be the first to admit that it’s been very difficult to prioritize learning software engineering best practices / product management / design & branding / building the software / writing in substack while trying to plan ahead.
But since I learned about the cycles and started using Linear, I’m on a 2 week writing & building sprint until Day 38. I’m still not focused enough with all the things that I’m doing and I hope that after this Project #1 I will be able to truly focus for Project #2 which I already have the idea to announce on Day 38.
See you tomorrow!
(⚡️BetterFriend Project Day 8 - 38)