Great apps are opinionated, and laser focused on solving a single problem in the best way possible. For a long time, we were trying to combine 3 functional components together: markdown pages, tasks, and calendar. We have been inadvertently trying to do it all. This caused confusion to our users, led to an unintuitive hierarchy of entities, and made development cycles longer for us.
This blog is about the mistakes, decisions, and the eventual course correction we have made, while building a slightly different kind of devtool - a knowledge base for developers.
Trying to Do It All
Our mission is to help developers organize their work - from the moment they are assigned a new issue, all the way to the point it's merged into the main branch. Our goal is to guide them throughout this process and make it easy when it comes to organizing their work.
It was clear to us from the beginning that we had to establish focus. We knew who we were building for - developers, but we haven’t defined which problems we are solving, and which ones we are not. We have found ourselves on the verge of becoming one of the tools that try to do it all, but fail to solve one problem properly.
Figuring Out What to Do
What helped us was being in touch with our users, talking to them on a daily basis, and relentlessly chasing critical feedback from them.
The primary issues were the lack of a main entity in the app and the presence of too many options without a clear preferred choice. We have also learned that most of the users were using acreom for a frequent job - breaking down large features, or issues they work on, into actionable steps, using pages. While our focus was scattered by solving every other job, we forgot to support the main job of our users.
We have decided to embrace this user job, and cut back everything else to place a clear opinion and focus in the app.
Making Hard Decisions
In order to shape the current product version into what we decided to solve, we had to cut features that users frequently use which is a painful process. We wanted to be fast and do what's necessary in the long-run, even if it meant sacrificing the happiness of some users in the process.
Laser Focus
Chances are, there already exists a solution for whatever you are building, with a single focus, that deals with a single job, and does it great. If you try to solve the problem, plus something else, you just can’t compete - your resources and focus are split into solving 2 problems.
In our case, the problem we were solving was the calendar, which was only a small part of our app. We have decided to cut it, because we could never meet the user's expectations when it comes to being a full-fledged calendar - we just didn’t have the right platform to do it.
Single Top-level Entity
Laser focus means having a clear hierarchy of entities and explicit opinions on how to use the product from day 1. One of the major mistakes we have made early was designing around same-level entities. In our case these were tasks and pages, representing action items.
Having to do so often slowed down our development cycles, because we had to support edge cases and confused ourselves about what is truly important. One had to go, and, based on our learnings from the feedback mentioned before, it was clear what we had to double down on pages.
This change made everything clear for us and the user. Suddenly things clicked and there was a clear opinion on how to get things done in the app.
Validate
Getting feedback on early concepts from users throughout this process is critical for a successful product pivot. What we did right here was to iterate fast on our explorations and share these iterations with our community. We were waking up to long threads of feedback which was essential for us to course correct and navigate these changes.
An important takeaway here is that a major change in the product UX is usually going to cause a pushback. Take this pushback as an opportunity to explore the job that profoundly matters to users, by diving deep in the followup questions, and compensate for it in a new design if it belongs to your newly defined direction. Also, keep in mind that the pushback is always part of changing the status quo.
Learnings and Closing Thoughts
Making everyone happy is hard, especially if you are making a simple app. There will always be a pushback from the users that are used to a certain way of how the app works. It is your responsibility as the maker to incorporate the feedback in a way that will make the tool you are building better.
Cutting features users are used to is a pain, but is sometimes necessary for further growth. The most important part of this process is to listen to the feedback, and decide what really is important. In our case it has led us to a better app, and some great solutions we wouldn’t have made otherwise - such as the Timeline of your day.
Above all, having a concise goal, purpose, and a main use case should be the main priority. From the moment they are assigned a new issue, all the way to the point it's merged into the main branch.Diverging from those leaves your efforts scattered, and the tool you are making, full of friction.
Now that we have regained our course, we are not diverging from it. We are building acreom around the single entity - pages - locally stored in your markdown files. And our every decision will be made in a way to keep the app laser-focused and concise.
TL;DR
Learnings on building a great product:
- Define a clear and narrow focus where you can deliver a 10x product.
- Great products are simple. Focus on multiple same level entities distract you from simple hierarchy and sidetrack you from your mission.
- Talk to users, a lot. By speaking to people we’ve found some things were not as important as we thought, and helped us focus on the core value.
- Don’t be afraid to make difficult decisions.
Top comments (0)