Consensus kills, busy work kills, flip-flopping kills


Consensus kills, busy work kills, flip-flopping kills

Last year I set a goal to "build non-time-dependent product & hit $5k MRR"

I finished on $0 MRR.

To call it a f**k up would be far too generous. A f**k up requires you to actually leave the starting blocks.

But in 2023, I promise things will be different.

In the past month I've changed a lot of things and I want to share. My goal this year is to build a DevTool with MRR and I want to share what I've learned and what I'm doing differently


What went wrong and how I'm fixing it

1) Lack of clarity on objectives

This is the single biggest reason I got nowhere and also the one that's hardest to solve. I flip-flopped between starting an DevTools marketing agency, scaling a developer newsletter, building a video editing tool. Nothing felt right.

Fix: set a goal I'm happy with

My goal is to build a tool for React Native developers. I have worked with React Native for the past three years so it aligns with my skills & interests. I'm in the process of selling or stopping my other projects.

2) Overthinking & seeking consensus:

I can't tell you how many times I had an idea and spent ages thinking of all the reasons it wouldn't work. Secondly, when working with my friend Nick we'd agree on a direction. But if the other person didn't like your idea, you couldn't do it.

Fix: clear launch goals:

This year I have to launch something every two weeks. Even if it sucks. Even if it's just an article. All my work is structured in this way. Secondly, Nick & I rotate decision making on what we launch a bi-weekly basis. So there is no consensus needed. If one of us feels passionate about something, we do it.

3) Too many meetings, too much responsive work

There is always someone to speak to. Always a tweet to reply to, an email to answer. An accounting chore to get on to. This caused me to do very little proactive work needed to push something forward.

Fix: one day for miscellaneous tasks & meetings

Now, I only take meetings on Thursdays (unless really not possible). I only do my chores on Thursday. It's given me so much more time to get my head down and be proactive.


Progress update on building React Native tools

In the last couple of months we've shipped a lot of experiments. Our goal is to find areas that resonate with React Native developers.

Here are some ideas we shipped & some brief notes on what we learned:

  • AppToggle - lot's of upvotes on Reddit. Interviewed 10+ React Native developers and found there was not a clear business demand considering how hard it would be to build.
  • WhatsApp clone (three part series) - lot's of upvotes. There's some interest in p2p calling and advanced chat stuff and we learned that people still find it complex and don't like paying big money upfront. We're interested in doing more experiments on this.
  • A/B testing with Supabase - almost no interest in this. Hard to say why.
  • SurveyLoop - launched on Product Hunt. Had one or two actual calls that felt like they could have led to a sale if we had the product ready. We're still not sure there is enough demand though. May do another experiment on this.

Lessons we've learned from our experiments:

  • We're sticking to established categories with competitors because we don't want to build something no one needs or has budget for.
  • Upvotes are good for your ego but basically meaningless. Real business needs are the gold standard
  • We're looking heavily at what people search for. If no one searches "React Native" + *what we're building* then we'll probably rule it out.

Consistent messaging & constant gentle pressure

I love novelty. Who doesn't? And how many times have you heard statements like the below?

  • "Wow, our product might actually be perfect for QA Testers!"
  • "This new feature changes everything"

But according to Jason Lengstorf - former VP of DevEx @ Netlify - this kind of sentiment can kill your DevTool.

As you experience some success, you need to move past "Let's build everything and see what sticks". You need to start saying no to most things unless it serves your Ideal Customer Profile meet the goal we set out to help them achieve.

And along with this, your messaging needs to stay constant too. It's better to stick with the same imperfect message over time than come up with a shiny, slightly better form of messaging every month.

This is because you will lose the consistent coherent story across the user journey and different functions will be making up their own version of the value proposition.

Check out the full interview here


You need to understand the adoption curve

Innovators are a very rare type of person. These are the people who care that your tool is built in Rust. They will struggle through your tool even when your docs suck, your product is buggy and you have no testimonials.

They will help you get valuable feedback and move on to the next phase of adoption.

Beyond innovators, you have early adopters. They are also very forgiving and see the upside of what your technology can bring. They'll take chances on you and fund Proof of Concepts at their company.

But once you get onto the early majority, things change fast. You suddenly need trust. Testimonials. Detailed docs. Integrations. They need to know your technology is here to stay and that there is low risk in adoption.

If you fail to understand these different types and where your company is, you are doomed to fail to cross the chasm between early adopters and the early majority.

I really enjoyed getting a primer in these phases with swyx recently and I think you'll enjoy this episode too.


You need conviction on who your target audience is

One more point.

While writing this email I listened to both episodes again and I noticed something funny.

Jason and swyx both worked at Netlify together and they both independently made almost exactly the same point.

You need conviction on who your target audience is.


Thanks for reading

This newsletter has more than usual on my own DevTool journey.

I don't promise to have all the answers (far from it) but I promise to share my honest findings and results with you as I go.

If you want to chat (on a Thursday!), please let me know.

Jack

Cemetery Rd, Sheffield, England S11 8FT
Unsubscribe · Preferences

Scaling DevTools

Read more from Scaling DevTools

Scaling DevTools Newsletter 11 Oct 2024 I just hit 100 episodes of Scaling DevTools. It feels symbolic for me because of this Mr Beast quote I read early on. "If you are just getting started on YouTube, do not expect to pull any type of viewership in your first year. If this isn't something you can accept, don't start. But if you can, then you need to do this: make 100 videos. It doesn't matter what they are because they will be terrible, but do something you like doing. Your first 10 videos...

Scaling DevTools 01 Sep 2024 One of the things I get asked a lot is "How do open source projects make money"? And this week I chatted with Vlad Matsiiako from Infisical - an open source secrets management tool. So I decided to delve into the how's and why's of Open Source companies. Vlad and I How do Open Source companies make money? Here are the main ways I've seen: SaaS/cloud - like any other SaaS, they sell a hosted version of their software. Within this there might be parts of the product...

Scaling DevTools 21 Jan 2024 This is my first newsletter for a while, hello! I just interviewed DevCycle - they made a huge pivot even though they had a big set of customers. What I admire most about them is that they are doing fewer things but doing them well. Also, I've released a new tools directory (more details below). The DevCycle pivot For most founders, landing Fortune 500 customers like GrubHub, Warby Parker & RBC Royal Bank is the definition of success. Imagine then, telling these...