It has now been almost exactly 12 weeks since I decided to write these emails and sent the first one - “Kicking off an experiment”. A lot has happened in that time. A quick recap:
In January my plan was to begin building Uno — a product-for-building-products. My expectation was that by Q3 I’d be financially comfortable enough that taking a big risk made sense. My visit to San Francisco in January convinced me that was the best place to build it, so I applied to OnDeck - an 8 week long program, based there, that connects 150 people who are looking to start their next thing. The plan was to dive in when the program kicked off in early March, and to also use that time to assess whether SF was somewhere I could see myself residing long term.
Shortly before OnDeck was due to start, I decided that using a smaller, less risky product as the launchpad for the bigger, riskier one was a good way to hedge my bets - both motivational and financial. And worked on getting Editmode ready for a Producthunt launch.
When the reality of COVID-19 set in, it became clear that even thinking about Uno didn’t make sense now. OnDeck was moved to an online-only program and my trip to San Francisco was postponed. Editmode became the sole focus.
Going forward from here, I expect these emails to focus pretty much solely on Editmode, chronicling its progress in the coming months.
What’s happened since the last email
I launched on Product Hunt 🎉 — by launched I mean “Told the world about”. I haven’t yet opened signups because I don’t think the product is at the point that it solves a well-defined problem for a single set of users. But we’re getting there. Thank you so much to everyone who got the word out and upvoted. Some figures: 293 Upvotes, 1130 website visits, 50 beta registrations. My main hope here was to validate the approach and gauge the appetite. I was super pleased with the feedback and interest, which showed that this is something people want, or at least claim to want. The email below was my personal favourite response.
I want to ensure what I’ve built solves a single problem for a single cohort of users, so I’ve been focused on understanding the different potential use cases in a series of calls with small tech companies, large tech companies, and agencies.
So far, the main responses been split roughly 40/60 between “I can see the value in this for X use case, but it’s not for us” and “This solves a real problem for us which we would pay for.“ This is promising, but there are still several larger questions that still need to be answered.
Web Sites vs Web Applications
When I spoke to people from tech startup & agency backgrounds, there seemed to be a consensus that, while the web site feature set was cool, they were also feeling the pain, and often it was a bigger pain, when making content changes in their web application.
I think the content API makes a lot of sense. It's basically a cloud-based application dictionary, or a hosted version of the Unix GetText API. I would've used a product like this in previous companies. I'm not sure why it doesn't exist.
— Sean Blanchfield
We do large scale Enterprise CMS integrations for people who need CMSes. And we need heavy duty CMSes for that, so Editmode wouldn't work for those projects. But we've had several projects in the past - mainly web applications - where the client thought they needed a CMS but they actually needed a simple content API. This would've been perfect for that.
— Martin Casey, CEO @ Arekibo
Our marketing team would love the inline-editing feature, although the surrounding feature set would also have to be robust, but our product & engineering teams would definitely use the content API to avoid having to put product content changes on the backlog, provided it could integrate with our translations. For example, we recently had to put items in a backlog to change Gift Voucher to Gift Card for our American teams - this took much longer than it should have.
— John & Patrick, Directors of Engineering, Product @ Phorest
At Airbnb we built our own simple content API internally called Dragoman. It's basically just a hosted dictionary. People aren't big fans of it because we never know where to find a particular string when we want to change it, because it doesn't appear in context, so the inline editing feature would be great. It also integrates with our translations pipelines so that would be a requirement too.
— Mohamed, Senior Software Engineer, Airbnb
So interestingly, while powering web applications wasn't initially the focus of the product, it seems from speaking to people that there is a real demand for it. This presents a dilemma: Do we put our early focus on building Editmode for web applications, or Editmode for websites? There are pros and cons to each.
The Content API Opportunity
Both web site and web application use cases have one thing in common - they sit atop a simple content API. We already have a term for this when it comes to talking about websites — "Headless CMS", but what I found interesting on the discovery calls was the amount of times the term "Content API" came up, either from me or from others. I wonder is part of the reason that this approach hasn't been popularized yet for web applications — that there's already technically a lot of content APIs out there (see headlesscms.org), so no one has thought to build a new one, but using a Headless CMS for the content in your web application is most of the time very clunky and not fit for purpose.
For example, here are some differences in the Content API requirements between web sites and web apps...
A google search of the term "Content API" yielded very few results - the only somewhat relevant ones were both CMSes. This got me to thinking: From a positioning perspective, there is a big opportunity to become the de-facto Content API. For example:
This is not to propose that Editmode would be just a Content API, just that the Content API would be at the core of what we do, not just one of the things that we do, both from an internal product development perspective, and an external product positioning perspective.
One big unknown here is, if you were to go this route, would you have to change the implementation to a content-as-code model, where any changes in the content structure (adding new models, fields, changing or removing attributes etc.) are defined in the codebase, akin to the rails migration model, instead of through the web interface. The x-as-code approach is clearly very popular, although in my opinion has been taken to unreasonable extremes, and this seems to be part of what makes Contentful popular with developers (See "CMS as code" on their website).
Go to market Questions
It seems likely that a high touch sales model with no self-service with a product like this may lead to a long sales cycle and slow growth. Of the qualified people on discovery calls who told me they would pay for the product right now, the only one I have a real chance of integrating within the next few weeks is the one whose codebase I have access to, because they’re a client. With the other two, we have email threads with responses coming back every few days, and I've done a few calls with each, but we still haven't even decided on which project we'd use it for because there are unknowns on both sides.
The absolute best way to solve this is to get hold of people's codebases and do the integration ourselves - this would be incredible. But is not going to work for anyone we don't know personally. Outside of that, it seems the best way is to provide a self-serve environment and let the developers sign up and integrate of their own accord, but to do that we need to build up trust and credibility, which will take time.
This is a big unknown right now and something I really need to prove out in the next few weeks. There’s no point in pushing on with the web application use case unless we have a realistic plan for driving adoption.
Goals for the next 3 weeks
Better understand the route-to-adoption if we go the web application route.
Integrate our first paying customer.
Work on improved positioning/marketing reflecting learnings from calls.
Summing Up
A content API for a website = A headless CMS
A content API for a web application = ?
If we build a content API that would power both web applications, and a certain type of modern-stack web site, we can support 2 different use cases. Both of these use cases exist in the same customer (tech and software companies) allowing us to price and sell (at least) 2 different products.
In the spirit of focus, we should focus on one use case first and get that right. If that is web applications, we should build for that use case whilst ensuring we don't close any doors for the web site use case with our product or architecture choices, and with a view to adding that product at some point in the future.
Still to be uncovered is whether we will need to adapt a "Content as code" model if we go that route.
Also still to be uncovered is the go-to-market. Do we do a high-touch, sales heavy model, or a lighter tough, marketing-centric model.
As always, questions/comments are much appreciated!
Tony