Keeping your product small and focused is the smart way to launch quickly and be agile enough to react to data you get from real users. The usual advice says to cut all the features you can and focus on the core value. But making a minimum viable product is much more difficult than it sounds.

When a client requests a new feature, it’s relatively straightforward for me to recognize when it could cause delays, usability issues, or other problems. After all, I’ve been a designer for 15 years and evaluating features is just part of my process.

But as a solo founder and product designer, it can be much more difficult to see those issues clearly in my own concepts.

I decided to take the leap and design a new software product (here’s why), and the first week I worked on researching audiences, creating product concepts, and brainstorming branding.

My new product will be called Mod&Dot. It’s a tool for saving devtools edits, then sharing and discussing them with your team.

But before I explain more about the process I used to arrive at that final concept and why I chose it, I wanted to write about the challenges I faced as a solo founder and designer planning out this new product.

Like I mentioned, while I’m experienced at helping clients decide when to cut features, doing that in my own projects is hard, and there are a lot of reasons for this. Here are common causes of a bloated product and how I overcame each of them:

Too much emphasis on user pain points

Pain points are important data to get from user research, but they’ve become the basis of what I think are questionable marketing approaches and can lead your product design the wrong direction.

Too much focus on user frustrations can lead you to create a product that tries to change peoples’ lives in big, ambitious ways, which is both very difficult to achieve and to market. I’ve made this mistake in the past (I once wrote the headline "Become a world-class designer" for a design course).

Conversely, user frustrations can also lead you to create products that are too small—like an app that addresses some minor frustration during the workday that isn’t big enough to motivate people to solve or spend money on.

So while I do look at user frustrations, it’s also important to try to understand where users are trying to go and what they want to achieve. For this product, I’m basing my design on user ambitions because it will allow me to have a more positive marketing message and build something people inherently value. (I’ll dig into the design reasoning in the next update, as I’m only at the sketching phase right now.)

Planning details too soon

The concept I ultimately chose has been in my notebook for 2-3 years. I kept putting it off because I had a concern about a technical aspect of the product: a security issue about injecting content into a live web page.

When I first had this concept, I spent a day researching that security issue: how to prevent unsafe script injection, cross-origin issues, etc, and decided it made the product too big and risky.

But I was making a classic mistake: trying to figure out a single detail before I even knew what the product was or what I was trying to help users achieve.

It turns out, I don’t need that feature at all to make this product useful. The core security issue was sharing website edits with other people, who then view them by reapplying those edits on top of the live site. That feature really wasn’t necessary and in 15 minutes of sketching I found a better way to share edits that completely avoids the security issue. Just share a screenshot and a code diff on a separate url, so that any code changes are never executed on a live site for a different user and there’s no security risk. Simple.

If I hadn’t worried about that detail, maybe I’d have build Mod&Dot a couple years ago.

Keeping up with the Joneses

A normal part of design and product research is to go see how other apps work and solve various problems to get ideas for your own design. If there are potential competitors you might feel pressure to build the same features they have too.

For example, a share feature where a user enters a friend’s email address to send an invitation email is a very common feature across many apps. As a designer it’s tempting to sprinkle features like this in everywhere because it’s so commonplace.

However as a solo founder who’s designing and building every feature, I have to be careful about that. It’s easy to add a day or two of development time with a trivial feature that isn’t strictly necessary for my app’s core focus, and this adds up very quickly. For example, I might not really need to send the invitation email where a simple share link copy/paste would do. Or, I could make all projects within team account automatically available to all team members so no sharing is even needed.

Finding smart ways to remove the need for extra features will help me build this app faster.

So while it’s okay to get out there and see what users are seeing in other products, every feature needs to earn its place. It can’t be there just because other apps do it, it can only make the cut if it’s part of the core design objective.

Over-designing

You’ve probably heard the term "over-engineering", but over-designing is possible too. When I work on a software design, I try to put myself in the user’s shoes and understand their perspective. That’s obviously a good thing, but it can go too far.

During user testing or planning out workflows within an app, it’s easy to find all kinds of edge cases and issues that pop up where the user does something unexpected or is lacking some knowledge to understand what’s happening.

For example, in Mod&Dot, I was really worried about what users would do if they wrote some broken, malformed CSS in devtools then sent me a support ticket saying my app was broken. I thought "Well maybe I need to build in some sort of CSS validation feature" and started sketching it out.

Obviously that’s a huge, huge feature and rabbit hole. A feature like that could delay my product for months. I can’t make my product force people to write good CSS. Users have to be responsible for something, and that’s ok.

Week one was: creatively draining

Overall I made a ton of progress this week, but as always I find research and product concepting to be extremely draining creatively. Naming things is hard! I’m feeling very anxious to move on and start designing this thing, because that’s always the fun part. But I know taking the time to think it through is always worthwhile.