What's New: How developers can think like founders

(from the latest issue of the Indie Hackers newsletter)

Are you a developer struggling to think like a founder?

• The key to shifting your mindset is understanding your customers and product without overthinking things. Founders weigh in below on shifting your mentality!
• Products and startups die for many reasons, but one that's often not discussed is the death of enthusiasm. Here's how to avoid that.
• Vance Lucas hit $1,600 in monthly revenue with BudgetSheet, his Google Sheets extension. Below, he shares how he built and validated with a focus on stability and quality.

Want to share something with over 95,000 indie hackers? Submit a section for us to include in a future newsletter. —Channing

🧠 Developing a Founder Mindset

by Jason Enter

I've been a professional developer for 20+ years. I want to shift my time and energy into various side projects, but the pragmatic skills that I use every day at work don't translate easily into skills needed when wearing these other hats. As a developer, you are working towards an end result, but the founder mindset seems to revolve more around weighing options. How can I shift my mindset to think like a founder?

Diary dive

Reuben Rapose spent six months developing his first product, and learned some very hard lessons:

As a developer, I tend to plan everything in detail and spend a lot of time researching. I've made it a point to now limit my research early on by spending no more than one day on it. At the end of the day, I open a diary and describe the problem that my product is aiming to solve. The main questions I try to answer here are:

• Who is the product for?
• How big is the audience?
• How much will they be willing to pay?
• Is the problem urgent or important?

I've found it useful to force myself to fill up an entire page with these answers, as the process leads to new perspectives on the problem statement at hand (ones that you might have overlooked initially).

On the next page, I write down my understanding of the distribution channels. Which one is most important? Which will be my primary focus? The important questions that I want to answer here are:

• Where can I find my customers?
• How can I actually reach my customers?

Narrow down your audience in order to target them easily.

Finally, I write about how my solution is going to solve the problem described on page one. Usually, this takes the other half of the page. Try to keep this part as concise as possible, thinking of it as a marketing pitch. Remember, you are not bound by your solution; what's most important is understanding the problem statement and figuring out distribution channels. Never limit your solution, and keep it flexible.

The most important point of this method is to avoid overthinking at all costs. Spend enough time to understand the problem statement deeply, but don't overthink it. I've realized that, as I build out these products, I tend to improvise and make the solution marginally better every day. This compounds over weeks and months, so the key is spending less time thinking of solutions, and more time understanding the problem.

Always think small. This will help you limit yourself and reach your launch date more quickly. Launching more quickly results in speedier feedback loops, which greatly increase chances of success.

Know before you go

Weaves87 points out a few key reminders:

• Know exactly where you're going to be getting your target customers before you write a single line of code.
• Evaluate the competition, and differentiate. Understand that differentiation doesn't just have to be a better feature set. There are marketing and branding ideas that you can tap into to set your product apart.
• Understand the value of time, specifically your own. For example, don't spend a bunch of time working on optimizing devops stuff when it could be much better spent validating your idea and getting user feedback. It's a daily struggle, but you'll need to prioritize and focus on activities with the best ROI.
• Start small. Literally just create the minimum viable product (MVP).

I really can't reiterate enough that you should remain aware of what you're spending your time on. It is very easy for us devs to get wrapped up in little details that are inherently meaningless. You should always be thinking from a user's perspective. Is this decision going to bring my users more value more quickly? If not, sideline it until the product is more mature and growing naturally.

Begin with the end in mind

Tom McLellan agrees that shifting gears to think more like a founder and online marketer can be tough:

I found Richard Koch’s The Star Principle and The 80/20 Principle to be great eye-openers, along with Perry Marshall’s 80/20 Sales and Marketing, Dan Sullivan’s e-books, and The Lean Startup.

There’s a great debate on starting something totally new versus finding an established product category where people are already spending money, and differentiating within that category. The "scratch your own itch" argument is also compelling because you can presumably spend more time building, while deferring some market research.

Another smart approach is to begin with the end in mind. Create a landing page, advertise it on Google, and get an idea of your search terms and cost per lead (i.e. “join the waiting list” signups) before writing a single line of code. Maybe even split test two project ideas that way, and choose the winner before writing any code. You can build an MVP with more confidence if you already have a funnel started, and you might even get feedback from some early waiting list signups.

I transitioned from enterprise systems integration and consulting into a bootstrapped full-time SaaS that covers my costs. It took a lot of trial and error, but it’s been really satisfying!

What are your tips on shifting to the founder mindset? Share below!

Discuss this story.

📰 In the News

from the Volv newsletter by Priyanka Vazirani

📧 Newsletter giant Substack isn't going for a Series C.

🛑 Hiring freezes and layoffs are a raging trend in tech right now.

👀 This subreddit is a free, DIY sperm bank.

🔄 RadioShack has returned as a crypto swap platform.

🤑 Facebook is paying users for privacy violations, and Google could be next.

Check out Volv for more 9-second news digests.

💀 Avoiding the Death of Enthusiasm

by Matthew Gordon

I've been a founder for about 22 years, and in that time, I've made a serious run at starting at least 12 products. Of those, four of them never saw the light of day. They died after I had put in some time and effort, but before being tested by the market. Why did that happen? What causes products to die before really getting out there?

Why products die

There are a lot of reasons why products die, and most of them are discussed regularly. There's an endless supply of books, videos, and blog posts about running out of money, failing to market your product correctly, or getting outmaneuvered by the competition. These are all real risks that kill their fair share of ideas, but the thing that kills more products in their infancy than anything else is the death of enthusiasm. Genuine enthusiasm is a limited resource. When it dies, the rest of the dominoes often fall like a house of cards.

I think everybody knows that when you run out of emotional steam for working on your product, it inevitably dies. Usually, though, I see it mentioned as a joke. But the death of enthusiasm is a serious threat that can and should be mitigated. The good news is that there are a few simple steps that you can take to make sure you finish the next project you start.

Keeping the enthusiasm

1. Estimate your interest:

The most important thing about managing enthusiasm is realizing that it drains over time. It doesn't matter if you're working full-time, a few hours a week, or just thinking about it. Your strategic enthusiasm reserves for this idea are draining as time passes.

This means that an estimate of your interest needs to be measured in a number of days or weeks. For the people who play on hard mode, the timer starts as soon as they have the idea. For those of you playing on the easier setting, the timer starts when work actually begins.

In my experience, you don't get to choose how your enthusiasm clock works. Just be honest with yourself. If you have an exciting idea today and wait a month to start on it, will you be just as excited as you are today? What about two months from now?

Try creating an idealized estimate assuming that you were going to work on this idea exclusively. If this was the only thing you worked on, how long do you see yourself being genuinely excited about it? A few days? A week? What if you spent the whole year working on just this idea and nothing else? Would that be awesome or did the thought of that make you worry you'd miss out on other opportunities? Use your head and your heart to find the sweet spot.

2. Estimate the work:

This estimate doesn't need to be great. You just need a ballpark. If you don't already have a process for estimating the work to make something new, I recommend our sketching process. A quick version only takes an hour or two, and at the end, you'll have a pretty good idea of what you'll want to make.

3. Estimate the work timeline:

How many hours per day or week are you willing to devote to this product? Given the work estimate above, how many days or weeks will it take for you to finish making what you want to make?

For example, say you sketched out an idea that you think will take about 40 hours of work, but you can really only squeeze in two hours of work a week. At that rate, your timeline is about 20 weeks. If you don't like the answer you get, is there something you can shift around in your schedule to work more on this idea each week?

Adding it all up

Do your estimates add up? If the work timeline is shorter than your estimated interest, you've got the gumption to take this to completion. On the other hand, if your work timeline is longer than your estimated interest, you're probably going to run out of steam.

Keep in mind that the starting date might change things for you. If your enthusiasm clock is already counting down, can you start soon enough? If the numbers don't work out, consider making a change to save yourself the heartache of another incomplete idea:

• Is that something you can cut to make the work timeline shorter?
• Do you have another idea in an area where you have more enduring enthusiasm?
• Do you have a less complicated idea in the same area?

This strategy is a few basic project management steps in a nutshell. It's best if you complete the above steps continuously while you're building, but even doing these steps one time before you start can save you a lot of trouble.

I'm blogging about project management a lot while we're building Burndown, a new project management tool that helps you get the important work done and focus on the big picture. If these steps sound like a good idea, and you'd like a tool that makes them a lot easier, join the mailing list to get access to our upcoming beta.

How do you maintain enthusiasm? Share your tips in the comments!

Discuss this story.

🌐 Best Around the Web: Posts Submitted to Indie Hackers This Week

📚 Seven startup books that are actually worth your time. Posted by Denis Shatalin.

📝 What are your goals for this week? Posted by Dan Kulkov.

👩‍🏫 Success is determined by three things. Posted by Lisa.

🧐 Is the App Store good for founders? Posted by Darko.

💻 Sales tips for freelance web developers. Posted by Weston Walker.

🤷‍♀️ How do I start building in public? Posted by Eflat.

Want a shout-out in next week's Best of Indie Hackers? Submit an article or link post on Indie Hackers whenever you come across something you think other indie hackers will enjoy.

📑 Vance Lucas Hit $1.6K MRR With His Google Sheets Extension

by Vance Lucas

Hi everyone! I'm Vance Lucas, founder of BudgetSheet, a Google Sheets extension currently making $1.6K MRR, and growing. If you have ever wondered if there was money to be made with extensions and add-ons, there absolutely is!

Here's how I built BudgetSheet!

Pick the right problem and explore the idea

Extensions and add-ons can be fairly limited by the platform you are building into, so you need to make sure that what you want to do is even possible first. I scratched my own itch and built BudgetSheet after a week of experimenting to see whether it was even possible with Google Apps Script.

Building something like BudgetSheet was not only possible, but I discovered how awesome and powerful Google Apps Script is! It let me do so much more than I ever thought possible, all with no hosting costs or web service to maintain. After about another month or two, I had a good first release on the Google Workspace Marketplace.

Charge money

Money is the ultimate validation. People will tell you all day long how cool your product is, but things get real pretty quickly when you ask for money. From the start, BudgetSheet has had a paid upgrade plan. The free version allowed users to connect one account, and the paid Pro version was required for connecting more than one account.

If you are looking for specifics, the easiest way to take money within the context of an extension or add-on, without having to build a payment page or web service, is to:

1. Use a Gumroad link along with the Gumroad License Key service. This will generate a new unique license key per sale that will be emailed to the user.
2. Add a screen or a form for the user to input their license key. Use the Gumroad License Key API to ensure that their key is valid.
3. Set a flag in the extension that the user has paid, and record their license key (I used Document Properties in Google Apps Script).
4. Add logic gates around paid features that check for that flag being set.

Focus on stability and quality after validation

Now that I knew the idea was possible, and that people would pay money for it, it was time to rebuild it with a focus on stability and quality. I could now fully justify investing a lot more time into this little side project to build something bigger.

Around the same time that I was evaluating all of the different approaches that I could take, Plaid reached out to me. I had gained so many users so quickly that Plaid had taken notice. The company reached out to me directly to let me know (very gently and graciously) that I was in violation of its terms of service. Plaid was actually impressed with what I had built, and were in the process of building something similar for Microsoft Money.

Plaid gave me nearly eight months to rebuild the whole extension around running all of the connections through my own Plaid account, and paying for them (the proper way!). This required a complete re-architecture, and running my own web service, database, etc. No more freeloading on Google Apps Script, and no Plaid fees!

The new setup was a lot more work, maintenance, and cost compared to the 100% profit margins that I was enjoying doing things the freeloader way, but it was the right thing to do. The end result was much higher stability for bank connections and transactions, and a much nicer onboarding flow for my users, with fewer manual steps. Since I could control the runtime, I could also run things faster and longer.

Have fun

BudgetSheet is a joy to run. Seeing real traction and getting positive customer feedback changes the game. Make a good product that you are proud of in a space that you love, and you will have fun running it along the way. It's the best way to stay sane and do what you love!

For more, feel free to check out my blog!

Discuss this story.

🐦 The Tweetmaster's Pick

by Tweetmaster Flex

I post the tweets indie hackers share the most. Here's today's pick:

🏁 Enjoy This Newsletter?

Forward it to a friend, and let them know they can subscribe here.

Also, you can submit a section for us to include in a future newsletter.

Special thanks to Jay Avery for editing this issue, to Gabriella Federico for the illustrations, and to Jason Enter, Priyanka Vazirani, Matthew Gordon, and Vance Lucas for contributing posts. —Channing