Seven Day SaaS Retrospective: Learnings and Next Steps

April 01, 2020

Well, it’s a few days since the end of the Seven Day SaaS challenge, and I think I’m finally starting to recover from the 90ish hour week I pulled to build an app and work my full-time day job simultaneously.

I seriously don’t know how people do this on a regular basis. For me, I find setting short-term sprints (between a week or two and two months at most) to be a reasonably effective way to motivate myself to work for so long, but it’s very draining.

Anyway, I’m happy to report that I have a finished and polished proof of concept to share with the world.

It’s an app called Bicycle, and it’s a spreadsheet killer targeted at business intelligence consultants who struggle to manage project, information, and visualization metadata.

You can check it out here: https://usebicycle.com.

Here’s a Google Sheet containing a demo dataset that you can download as an Excel workbook in order to upload to the demo, which is front-end only (no backend at all right now, for POC). Also, there’s no support for other upload formats at the moment.

Here’s what it looks like:

cover image

As one BI consultant that I talked to today put it, it’s a glorified spreadsheet, so the name “spreadsheet killer” is a little overly dramatic.

The value proposition here is that it prescribes a single, unified way of storing project data. It’s all indexed, searchable, and will ultimately be able to present different views of the same data, depending on the needs of the user requesting it. Think spreadsheet views of source columns and business logic for the engineer, generated documentation for handoff, health check data for product managers, and so on.

Where did I get this idea?

As I mentioned in my previous post, this is a project that I’m building for my dad, who just so happens to be a BI consultant.

His focus is on UX design, so he’s a more visually oriented person, and looking at giant spreadsheets makes him Not Happy. He’s also very organized and keeps his spreadsheets tidy and functional. However, that’s not necessarily true of the other people on his teams and projects, who all store and document data in different places and ways.

This is really frustrating and inefficient for him (and often everybody else involved), but there aren’t many solutions beyond ad-hoc, homegrown systems that vary practically from project manager to project manager.

Now, there are plenty of other unique things about my dad and his problems, but I’m not here to talk about him. Instead, the reason I bring him up specifically is because of a Paul Graham essay that you’ve almost definitely already read – and if you haven’t you should – Do Things That Don’t Scale.

It’s an amazing essay, and in it he talks about the importance of making your initial user(s) happy:

You should take extraordinary measures not just to acquire users, but also to make them happy.

He goes on to say:

I was trying to think of a phrase to convey how extreme your attention to users should be, and I realized Steve Jobs had already done it: insanely great. Steve wasn’t just using “insanely” as a synonym for “very.” He meant it more literally — that one should focus on quality of execution to a degree that in everyday life would be considered pathological.

And finally (and most pertinently):

Sometimes we advise founders of B2B startups to take over-engagement to an extreme, and to pick a single user and act as if they were consultants building something just for that one user. The initial user serves as the form for your mold; keep tweaking till you fit their needs perfectly, and you’ll usually find you’ve made something other users want too. Even if there aren’t many of them, there are probably adjacent territories that have more. As long as you can find just one user who really needs something and can act on that need, you’ve got a toehold in making something people want, and that’s as much as any startup needs initially.

I just love this idea. It’s incredibly compelling. I’m a perfectionist, and I care deeply about building equally beautiful and utilitarian solutions to peoples’ problems. So the current path forward in my mind is clear: build a solution to the problems that my dad is having as described above, and build one that makes him really happy.

Now, I do want to attach a disclaimer here: it is, of course, essential not to get too bogged down in building and wind up never lifting your head to go out and find users. Paul Graham talks about this in his article. Don’t get trapped into thinking this is the only important thing. It’s just the tactic I’m trying now.

That said, my dad is an ideal alpha user due to our relationship, the industry he operates in, and the contacts he has.

So, moving forward, one of my big goals will be to tailor this software to exactly his needs. In so doing, I’ll be building software for the category of users he represents, who I cannot easily quantify without a lot of research but who no doubt exist.

It’s like lookalike audiences in Facebook and LinkedIn (and here’s an analogy that’s crossing over from my digital marketing days). The great benefit of lookalike audiences is that they can be a black box: if you have an existing audience, you can simply use the social platforms’ existing algorithms to target the people that are like them.

Of course, the effectiveness of lookalike audiences is dependent on the quality of the lookalike algorithms, but the concept is still directly applicable: if we can build a tool with satisfies an existing audience’s needs, we’ll by necessity be satisfying the needs of the category of users they belong to.

A related concept is the 1000 True Fans theory (original article here, great writeup at Andreessen Horowitz here).

If you can make a small subset of users really happy, you stand a good chance of making a larger set of users happy as well.

Seth Godin also talks about this a lot. The podcast where I first heard him say it is The Business of Authority (hat tip to Jonathan Stark of Hourly Billing Is Nuts).

He’s talking about building authority through writing books, but I think the concepts are all the same at a base level, whether you’re producing a book, a podcast, a SaaS, or an underwater basket weaving masterclass. The money quote there goes like this (Seth speaking, emphasis mine):

The real signifier is did someone other than you tell me about your book. That is the signifier because now the book is serving its true function which is it is a permanent container for the ideas of a single person. If someone tells me about your book, your book has just increased your authority. What we have to begin with is you have to write a book that other people will choose to talk about in a way that gives you authority. That is really hard to do. Do that first.

This quote is kind of strange out of context, but when I was drafting this article it rang a little silver bell in the “do things which don’t scale” department.

The key takeaway that Seth shares here is how important it is for somebody other than yourself to share your content (app, book, whatever it might be) – and the inherent authority it lends you and your material.

There’s a strong connection here to the 1000 True Fans theory and of course Do Things That Don’t Scale. The point of all of them is this: produce something which is incredibly high quality and let your work speak for itself, through the mouths of other people.

Not putting my eggs in one basket

Now, that’s a lot of proselytizing one particular viewpoint which is almost a “build it and they will come” mentality, so I think it’s time for a dose of real-world pessimism: you can’t simply build a better mousetrap and hope the mice will wander on in, because this is the Real World, and the Real World Sucks, baby.

Therefore, given the amount of effort and expertise I’ve put into building this software, I’m hardly planning on risking all of my eggs in one basket.

Although I will be focusing on working with my dad and tailoring the software I’ve built to his needs, I’m also going to be putting some serious hours into organic outreach via LinkedIn connections, Slack groups, etc.

Right now, my goal is to reach out to twenty BI consultants and people in the industry each day for the next two weeks, both as a form of market research and also by way of establishing an initial user base. This will constitute 200 outreaches, so we’ll see by the end of that if we can drum up any interest.

If not, I’m going to take a cold, hard look at why things aren’t working and reevaluate from there.

I’m looking to get in touch with business intelligence professionals, so if you know anybody please send them my way. Really appreciate it!

Ta ta for now,

Elliot