What's New: What users want from your SaaS (advanced edition)

(from the latest issue of the Indie Hackers newsletter)

Do you know what your users truly want?

• In this final installment of our 3 part series, we peel back the layers on identifying the job that your users "hire" your product to do, and how you can leverage this when considering new features.
• There's a ton of standard startup advice out there, but below, check out these 7 unpopular opinions. From "lose customers," to "don't listen to feedback," these takes offer a different perspective.
• Founder Nilan Saha challenged himself to build a startup in 24 hours, announced it on Twitter, and...failed. Here's what he learned from the experience, why he's going to try again, and what he'll do differently next time!

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

🔎 What Users Want From Your SaaS

from the Growth & Founder Opportunities newsletter by Darko

This is the final post of my series on how to discover what your users want from your product. Check out the first post here, and the second one here.

In this advanced edition, we'll cover how to structure jobs-to-be-done (JTBD) statements, get to the core of your JTBD, and more!

The magic questions

Is the job you think your product is helping people accomplish actually the core job that people hire you for? If you don't know the answer to this, just keep asking "why" until you arrive at a human reason.

For example, suppose a person tells you that the reason they're trying to determine the best price for a product is to save money for the wellbeing of their kids. This is a human reason; there’s no point in asking further questions like: “Why do you want to improve your children's wellbeing?”

To get a better understanding of where your job fits in the big picture, ask people what happens before and after it. For example, ask what they do after they’ve accomplished the job.

Also, try asking questions related to monitoring whether the job is being done: “How will you monitor whether you’re maintaining employee engagement?”

Other questions:

• What modifications do you need to make after doing the job to ensure it’s being done successfully?

• What needs to happen to successfully conclude that the job is done?

• What needs to be monitored and verified after the job is done to ensure successful completion?

As for finding out what happens before the job, ask a question like: "What needs to be identified, prepared, set up, located, confirmed, or gathered before the job, in order to get it done successfully?"

If the JTBD is too broad or vague, identify the individual jobs that will make up the big job. You can then later run them through the satisfaction phase.

Here’s an example: The main JTBD is to learn a language. In order to execute this job, you first need to identify the language that you want to learn. You then need to gather study resources, allocate time to learn, and start the main job (actually beginning to learn).

In the end, you need to decide whether the job was done. Was the language learned to the level of satisfaction?

There are potential product ideas in all of the steps on the above chart. That's the power of deconstructing JTBD.

Many products fulfill just one step in the overall, big picture JTBD. There are potential products in each of these separate steps, or one that unifies everything.

Your goal when interviewing customers is to find the core job your product is hired for, then go from there.

Jobs vs. features

A job gives you the problem that needs to be solved. A feature gives you a proposed solution (which may or may not be the best way to solve the job).

Many people assume that more features equate to more value, but here's the thing: A feature can hurt a product if it makes the specific job that the product was hired for more difficult to accomplish.

Let's say your company manufactures drills, and people hire your products for this JTBD: "Make a hole." Adding fancy features that slow down the process of users being able to unpack the drill and make the hole hurts your product. Without having a clear idea of the JTBD that your product is hired for, you’re blind to user needs; then, it’s easy to make these kinds of mistakes.

Here's another thing: People often don’t know what solutions (features) are possible for their problem. You might have neat software development skills, but people don’t always know what’s possible with them, thus limiting the usefulness of features they request.

How do you stay aligned with the JTBD when people start requesting features? Immediately ask them why they want the feature, and what they would be able to accomplish with it.

It’s easier than you think to get this wrong

People often confuse the difference between a situation and a job. JTBDs aren't usually based around products, but around situations.

Distinguish between a situation and a job. “Finding that an employee is spending more time than usual to accomplish something” is not a job. It’s a situation that potentially calls for a JTBD. A JTBD would be: “Keep track of an employee's time when she's working on a project.”

A little quiz: Which of these is a JTBD?

1. Have smooth hair.
2. De-frizz my hair.

Number one is a benefit, not a job. It’s an end state, not a process. Number two is a job you’re trying to accomplish. That’s why I highly recommend starting with a specific action verb to identify a JTBD.

Further deconstructing your JTBD

People don’t usually hire your product because they want to do something. They hire it because they want to do something better or cheaper. To classify something as “better,” it either needs to be:

• Faster.

• More stable: Eliminate unpredictability and increase accuracy.

• Provide more output: Eliminate waste and inefficiency.

There are measurable ways to see how well a specific job is being done. We will use a statement similar to the JTBD template:

Make sure that the questions you ask focus on the job your product is hired to do, not the product itself. Suppose the job your product does is “manage social media profiles.” Your exact question should be: “What makes managing social media profiles time-consuming?” Not: “What makes using [your social media management tool] time-consuming?”

After asking these questions, I might come up with the following statements:

• Minimize the time it takes to write what I need to write.
• Minimize the likelihood of adding a duplicate task.
• Increase the likelihood of getting the noted task done.

These are statements by which you can actually measure how useful your features are once you implement them.

It’s all about what you focus on

Here are some good resources for further reading on the JTBD framework:

• Designing products around customer jobs.
• The jobification of weather apps.

You may be constantly bombarded with feature requests and varied feedback on what your users want. I hope this series helped change your focus from listening to which features your users want, to understanding which jobs they are trying to accomplish. This simple focus change will dramatically alter the way you approach UX design, making it easier to give your users what they want!

Will you use the JTBD framework? Let's chat below!

Discuss this story, or subscribe to Growth & Founder Opportunities for more.

📰 In the News

from the Growth Trends newsletter by Darko

✅ Facebook and Instagram's paid verification has launched in the US.

🔊 Four essential tips to boost your audio ads.

💸 $143B was lost to fake traffic in 2022.

📵 Here's how many countries have banned TikTok so far.

🖼 Coca-Cola is inviting fans to create AI art using its iconic imagery.

Check out Growth Trends for more curated news items focused on user acquisition and new product ideas.

🤯 Seven Unpopular Startup Opinions

by Dan Kulkov

I'm here today with seven lessons from our journey growing MakerBox. These may initially seem counterintuitive, but they actually work!

1. Don't listen to the feedback

No matter what you put out there, somebody will think it's terrible.

This rule applies to landing pages, SEO articles, product videos, and marketing emails. People will always find weak points.

But, in reality, most of these weaknesses can be ignored. In an ideal world, they wouldn't exist in the first place, but many of them don't impact your business that much.

Founders should ignore the majority of the feedback. This is the way to build a calm, anxiety-free business.

2. Don't acquire more users

You don't grow by acquiring more users. You grow by acquiring more activated users who understand your product's value.

Getting thousands of website visitors with a poor marketing funnel will result in nothing. People will just stare at your landing page for 10 seconds, then leave.

Instead, focus on your activation. Learn to communicate your product's value with free trials, product videos, social proof, freebies, and other tools.

3. Forget about tactics

Every week, somebody on Twitter creates a program promising the secret tactic to scale any SaaS to $10K MRR.

Don't get distracted by shiny object syndrome. Tactics, frameworks, and templates come and go. Foundational rules and channels stay.

SEO didn't go anywhere. Email lists are not dead. Social proof still sells like crazy.

Pay attention to marketing principles that worked 10 years ago, and will work in the next 10 years. They may not be as shiny, but they do the job.

4. Lose customers

Don't try to please everyone. It's impossible, and trying to do so will actually hinder your growth.

Do you have the ideal customer profile? Perfect. Write copy and optimize your sales offer around that.

Then, go further. Find your worst customer profile. Ensure that your copy, features, and offer will push these users away from your product.

This focus will convert ideal customers better because they will see that you are ready to sacrifice other segments for them!

5. Don't plan

Creating a 12 month marketing plan including every possible campaign is so appealing, but does it really make sense for indie hackers?

In short, no. Why?

• The market changes too fast. There is no point in planning things that won't happen.
• Your powers are flexibility and speed. You can adapt way faster than large corporations. The more rigid your plans, the less you will be able to leverage this strength.

Create a flexible marketing strategy for each month, but be okay with changing it.

6. Sell before building

Spend one weekend creating an early bird landing page to test demand, then spend one month creating an MVP to further validate.

If people are unwilling to buy your product without seeing it, it may not be worth building.

7. Read less

Stop bookmarking every startup tool Twitter thread. Stop listening to every growth podcast. Stop subscribing to every marketing newsletter.

Sure, it's definitely helpful to get new ideas and challenge your status quo, but at some point, you actually have to do the work.

Less FOMO. More results. Highly recommend it.

Do you agree with these tips? Share your thoughts below!

Discuss this story.

🧠 Harry's Growth Tip

from the Marketing Examples newsletter by Harry Dry

Make your copy memorable by adding alliteration.

Go here for more short, sweet, practical marketing tips.

Subscribe to Marketing Examples for more.

⏳ Nilan Saha's 24 Hour Startup Challenge

by Nilan Saha

Hi, indie hackers! I'm Nilan Saha, and last Sunday, I tweeted that I would build a startup from start to finish in 24 hours.

I knew that I wanted to build a Twitter growth tool, but aside from that, I hadn't done any research. The plan was to decide on key features, build them out, then release it the same day.

Fast forward 24 hours, and I failed to do what I said I would do. I posted on Twitter about how I hadn't accomplished the goal, but I wanted to post a more detailed look here to discuss what happened! Let's dive into my mistakes.

Chose a high code project with lots of API Integrations

Building a Twitter growth tool requires being very closely integrated with multiple Twitter APIs. Of course, that means reading the documents, understanding them, coding them, and debugging them. This was just a lot to do.

Focused too much on design

I am a sucker for good design. I even have a website dedicated to beautiful landing pages.

I spent almost double the time than I should have on the design. I ended up trying different things. I changed the code rather than just building from my simple Figma design. Although good design is great and much-needed, it often does not help with validating core features in a MVP.

Tried to push my own authentication

Getting "Log in via Twitter" to work was a pure pain. I knew about alternatives, like Firebase and Next.js, that make authentications super easy. However, I had never used those before.

I thought it would be faster to code it up on my own rather than trying to make them work. I was so wrong.

Got distracted by fame

My tweet was going viral as I was building all of this stuff. I was excited about it, and constantly replying to people.

I was way too distracted to focus on one thing for even 15 minutes straight. I should have just focused on building, which was the intention in the first place!

Closing thoughts

Now that I have the scar tissues from this failure, I know what to do and what not to do. I have decided to try again, and I hope these lessons help someone who's thinking of doing a similar challenge!

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 Darko, Dan Kulkov, Harry Dry, and Nilan Saha for contributing posts. —Channing