In the following exchange, Alphadoc’s co-founder and CEO, Job Rietbergen (@Job-Rietbergen), distills how they have spent their first year seeking out “brutally honest truths” on customer problems and on how they are iterating to address those problems.
He also shares how he met his co-founders (who had experienced the same itch), why he chose to build Alphadoc of all the other potential ideas that had previously made it to his journal, and how they’re using manual onboarding as a customer intent filter.
— Growth lessons, founder-market fit, and Alphadoc’s origins
— How to learn — ask, pitch, and research — better
— Manually onboarding users for a tool that enables PLG
Growth lessons, founder-market fit, and Alphadoc’s origins
My background is in growth.
I’ve worked with lots of startups, scaleups, and corporations to implement growth in their organizations. After doing it for seven years, I made a decisive jump and became a Chief Marketing Officer at a health-tech, API product (Founda).
There, our go-to-market was focused on selling to hospitals and similar big institutions in healthcare. Even then I was looking at how we could lower the barrier to entry for developers or anyone else to just come in and play around with the product.
Essentially identifying product-led growth levers. Giving away stuff, so that people could experience some of the core value themselves and convert on their own, even though our sales motion was mostly top-down.
Because I had joined early, it also meant that I was very much in the trenches. To experiment and figure out PMF. I built a new website with low-code tools that’ll allow us to iterate fast on our messaging. I also sat on sales calls to draw on what was resonant.
We had started with one proposition and quickly learned that people expressed much more interest in something else.
Which had really been a side track from the beginning, but then we went all-in based on the many conversations and learnings we’d had from the industry.
Given my technical background, I was basically building a lot of the developer-centric PLG capabilities myself. And being a CMO I also saw the impact this could have on the sales and marketing side of the business. We’ve all seen how companies like Stripe and Twilio leveraged developer experience to grow into the companies they are today.
I could not find tools that solved for those developer experience problems, so I thought perhaps it’s time to introduce a solution myself. Funnily enough, when I was about to leave the company, Alphadoc’s founding story became immediately interesting.
During my conversation with Founda’s founder (someone I had worked really closely with in search of a fitting proposition for the product), he suggested that if I wanted to pursue the path of entrepreneurship, then I should definitely connect with two people: his former co-founder (CTO) and the first employee from his previous fintech startup.
And that’s how I met my co-founders.
They had previously built a white-label payment gateway, which was sold to banks and other major financial institutions. And was acquired, a couple of years ago, by Verifone (a huge US-based payments company).
So they had experienced the same troubles up close from the fintech point of view. On the one hand, they were building integrations with some old school, legacy systems in payments. On the other hand, they were proposing a single-API, modern solution.
We all said: “why not solve this together?"
As I noted earlier, during my time at Growth Tribe, I saw hundreds of businesses and worked with many of them. You do get a lot of learnings (for ex: how ruthless B2C can be, as people are spending their hard-earned income on something new vs B2B, where costs and budgets for tools is a clear thing) and inspiration from that experience.
And I have a big backlog of ideas that I’ve collected over the years.
Why did I decide on the Alphadoc idea?
It wasn’t so much about the category per se.
It was the fact that all three of us had faced this problem acutely. We spoke with around 50 people at different companies who could be potential users and it had become clear that this was indeed a widespread issue.
Then, more importantly, this problem space was much closer to my heart.
Because I’m really happy as, what one would call, a T-shaped player. That is I love being busy with tech stuff such as coding, ML, and AI. But I also like to think a lot about the commercial side of things. Growth. Data. The whole picture.
And I felt that the Alphadoc idea combined engineering and business problems in just the right way for me to pursue it.
How to learn — ask, pitch, and research — better
When we launched last year, we went out with nothing more than just a simple marketing website and some prototypes (basically clickable images we had created in design tools).
My perspective was the opposite of “build it and they’ll come.”
I wanted to put our idea in front of as many people as I could and gather lots of learnings before we started building. I didn’t want to be, as many founders approach it, in full stealth mode for 1-2 years.
I had seen how that restricts startups to a handful of users, at best design partners.
We were instead keen on getting feedback from as many sources as possible. In those early days, finding the right qualitative data to iterate our hypothesis and base our first decisions on, was most important. Also, it helped us attract talent and gain early momentum.
Once you grow a bit, you can put up more quantitative metrics and dashboards to get more granular insights. In the beginning, though: just scaling the number of people you speak to, the number of calls you have, and thus what you’re learning, is enough.
You have to be able to ask the right questions in these calls, so that people give you honest answers. Because it’s very easy for people to say they love what you’re doing and then never use/convert/buy. That’s the big challenge of early stage research.
So on these calls, broadly, I really try to get a super contextual sense of:
- Their past behavior instead of asking “would you buy this?” as people mostly tend to please you with the latter,
- The size of the problem; “what is your hair-on-fire problem in this space?”
- Connected issues that are top-of-mind for them
- The urgency with which they want it solved; “what is your timeline to solve this?” and “have you tried solving it already, if so, how?”
Another thing that’s worth remembering is that you have to sell what’s available today.
When you’re talking to investors you can pitch the big vision, where you’re heading in 5-10 years, and how big the opportunity would be. But when you’re talking to potential users and customers, it’s all about one thing: Can you sell them on, or rather can you get them hooked on what you have today?
I have 60 of these calls each month. 3-4 a day on most days. Sometimes more.
And I often speak very little about the product.
Maybe just the last 5-10 minutes of a 30-minute call are really about the product that we’re building.
The first 20-25 minutes are spent gauging their workflow and whether our product, as it is today, would fit their needs or not. It’s tempting to start selling something we’d build six months down the line, of course.
By avoiding that we’ve discovered (somewhat painfully) a lot of companies and personas that we aren’t a great fit for.
For example, when we speak with large enterprises, they really love the visual storytelling-based onboarding for developers. But they often have systems (even if they are far from perfect) in place.
And they say, ‘how can I combine Alphadoc with what I already have?’ Instead of our pitch, which was, ‘let’s replace what you have with our product.’
They basically needed a lower barrier to entry to get in. We saw this feedback often enough for us to build embedding possibilities into the product, so that they can embed Alphadoc into their stack and we can offer that first win faster.
This research is also helping us think better about different personas we (can) serve.
On the buyer’s side, we have people (devs, product managers, technical writers) who work on developer experience teams and create documentation, for example. Then, on the consumer side, we have the developers consuming that experience.
We need to figure out what all these (sometimes overlapping) personas need and want. So lately, we’ve been broadening our set of research conversations to get a better understanding of what sorts of motivations drive all sorts of buyers and users.
The trick, again, is to do a lot of these calls. Then you start seeing patterns. I have a Google doc where I just type out summaries and soundbites from each chat. That doc is over a hundred and fifty pages of insights by now.
Such a valuable source of information.
And I know it’ll be easy to use AI tooling for summarizing notes. But I find that taking a few minutes after each call and writing down a couple of bullet points based on what I thought was most notable, works best during this phase of learning.
Manually onboarding users for a tool that enables PLG
Although what we’re building with Alphadoc will help companies create that bottom-up, developer-led motion, we ourselves made a conscious decision to not yet have a full, self-serve onboarding on our website.
Because we wanted to have a touchpoint with everyone going into the platform.
To learn what’s most important to them when they’re signing up.
That bit of thoughtful hand-holding is important during the early stages of development.
Our reasoning is that if someone is not willing to have a quick chat, they are far less likely to either give us valuable feedback or money, which has so far turned out to be pretty accurate.
At the same time, it’s been key to finding 1-2 features that are 10x improvements compared to their current workflow, so that people are willing to cut us some slack on not yet having certain other things.
We’re now planning on going into general availability in some time and we then plan on offering people the option to get started on their own. As everyone, especially developers, want to try stuff out and expect easy access.
Then, again, it’s not like developers won’t get on calls to chat. They’re very much open to it if they see that what we’re doing is interesting. That’s the magic word, really.
Are we talking about a problem and do we have a solution that they’d care about?
Related reading from the Relay archives:
— Common Paper’s co-founder, Jake Stein, on (not) confusing an investor pitch for a customer pitch
— Cord’s co-founder, Nimrod Priell, on how user research (not pitching) helped them hone their proposition
— Spellbound’s founder, Akshaya Dinesh, on how design partners are really early users