2
1 Comment

I’m taking six months out of my big tech job to try and build a SaaS company [Month one]

Like the title says, I’m currently taking six months to build a business. I took a break out of my job as a design team lead for a big tech company in June.

After a tough year in lockdown cooped up doing video calls, I felt like I needed a change.

As someone who’s designed, coded and planned software products for companies for a decade, I’ve always wanted to try build my own product and this just felt like the right time to do it.

🟨🟨🟨🟨⬜️⬜️
I’m already four months into the six months, so I’ll add a post here every week or so to document my journey so far, starting with month one.

💡 The (original) idea

During our spare time, a friend and I had been tinkering on a SaaS geared towards UX Designers and Product Managers, that made it easy for them to take screenshots of user journeys in their browsers.

We are both people that build software products, and have worked in design, development and project management. We saw this idea as a novel way to help make the tedious chore of taking screenshots, stitching them together and sharing them with team members a little easier.

We decided to use the idea to apply for an early-stage entrepreneur programme. The programme offered a monthly stipend and some supports like AWS credits and workshops, to help develop ideas. At around May of this year, we found out we’d gotten onto the programme.

What we did during month one

The main goal of our first month on the project was to do a tonne of customer research.

We’d shown some early prototypes and mockups to designer friends, but we knew we hadn’t done nearly enough genuine validation.

That’s when we came across The Mom Test, an excellent book by Rob Fitzpatrick that helps non researchers like me to structure conversations with users and potential customers, in a non-leading way.

After reading the book, and talking to a researcher friend, we stubbed out some core goals for our round of research.

Our main motivation was to address our biggest failure points, and to learn more about designers:

✅ Validate (or invalidate) our assumed pain points

🖌 Understand what tools designers use currently to solve this problem

😫 Uncover additional, overall pain points of designers

We started using Dovetail as a research repository, to record interviews, notes and the interview statuses of different people.

We reached out to contacts, and new people through LinkedIn, and then started setting up calls.

At first, we’d take notes on paper, but after a while, we started using Otter to transcribe notes during calls.

We interviewed around 30 designers in our first month.

What did we do with this mountain of research, next? We used a research guide from Gitlabs, this excellent video by Erika Hall, and advice from researcher and designer friends, to come up with a synthesis plan.

synthesis
Image source: Miro

Using Miro, we lined up a number of key quotes from our 30 interviews, then clustered them into groups, and discussed the themes we saw emerging…

🤓 What we learned

When we zoomed out of our Miro board full of quotes and pain points from designers, one thing was blatantly obvious:

Designers were very content with the way they were currently solving the problem we had chosen, and didn’t come close to being in their top pain points.

You might think this realisation was incredibly demotivating. We’d just uncovered that we were solving a problem that no one really cared about.

And while it was a sobering realisation, I felt a big sense of relief. We now had a clearer picture of who we thought we were building for and could have a conversation about how we wanted to continue.

The main thing I learned this month is that if you’re working with others “research is a team sport”. If you don’t synthesise and discuss research with your team, you’re leaving your learnings on the table.

The other important thing I realised is that we’d started coding way too early, and had fallen in love with our idea. Advice to not do this is repeated everywhere, but it’s still an easy trap to fall into. Confirmation bias is a powerful thing, even if you are aware of it, it doesn’t make you immune!

Month one in numbers

🎤 Interviews: 30+
💰 Earnings: $0
💸 Costs: ~ $20 (Software, subscriptions)

2️⃣ Coming up in month two

We decide to pivot, while staying in a similar problem space, with a similar set of users. We start interviewing product managers, and run a Google Ventures Design Sprint to quickly test out ideas, before coding anything.

👨‍💻 What I’m working on now

I’m currently working on a product that helps founders, product managers and designers to validate user needs and feature ideas before coding. This comes after months of trial and error of validating my own ideas, and reading as many books on the topic as I could. I wish I’d had something like this in month one, so I’m scratching my own itch.

That’s it for month one! I'm interested to get your questions and feedback on what we did during our first month. What would you like to hear about next? I'm also sharing my daily progress building in public on Twitter, if you'd like to follow along.

Trending on Indie Hackers
Getting first 908 Paid Signups by Spending $353 ONLY. 24 comments I talked to 8 SaaS founders, these are the most common SaaS tools they use 20 comments What are your cold outreach conversion rates? Top 3 Metrics And Benchmarks To Track 19 comments How I Sourced 60% of Customers From Linkedin, Organically 12 comments Hero Section Copywriting Framework that Converts 3x 12 comments Join our AI video tool demo, get a cool video back! 12 comments