atlas is the result of a startup that didn't work (Palabra). Palabra was born out of the urge to build a product, without thinking about who the customers were or whether there was a business behind it. I think the year I spent working on Palabra, trying to do it backwards (selling something that was already built, with a team behind it), is why Atlas didn't exist until we already had customers.
Atlas's first product was a tool to handle accounting for people in Latam working for US companies. we set ourselves the rule of not building anything until we had validated there was real interest in buying a solution like that. my prototype was a Stripe link for a $25/month subscription, and my way of validating it was scheduling calls with people I knew (most of them from Twitter) and trying to sell it to them. there was no app, no scripts, no development of any kind. literally all that existed was a payment link and my booked calls. on those calls I'd explain to these potential customers what problem we'd solve for them (registrations and tax filings, monthly support, billing, etc.), and my goal was to get them to buy. on the second day of trying to sell it, we had two purchases on the call itself (I waited while they went to find their credit card), and we sold 40 subscriptions in the first month. that's how we knew there was a real need, and only then did we decide that Atlas (which had a different name back then) should start to exist.
not building product until you have customers is in the DNA of what we do, and now, 2 years later, I find myself asking some questions about it:
- how do you keep this practice alive once you already have an established team?
- testing new ideas without product means a lot of manual work. I wonder when the right moment is to scale it and stop the manual tasks.
- what does "validated" actually mean? e.g., if the ICP changes, do you have to re-validate from zero?
a related question I keep coming back to, even if it's not strictly the same: what's the sweet spot between developing new product (i.e., dreaming up ideas that might serve a customer out of thin air) and only building what a customer needs or asks for. having written it, I think the answer is probably the process described above: you don't build product until you have validation, and the only way to get validation is with a customer paying.
the stages of the process
I think it's worth laying out the stages of this process. a first draft:
1. idea: we think about what we want to build and for whom. the thing we build has to be a single, small product, and it has to have a defined ICP.
example: employees would like to access their salary before payday. the ideal customer is someone who works at a company earning under $X and who has debt or spends more than they make.
2. define a prototype: the prototype has to meet a few conditions:
- fast: building it shouldn't take more than an afternoon. remember we're not validating an app, we're validating that a problem exists and that our ideal user is willing to pay to solve it. there's an assumption underneath: if the problem is genuinely a pain for the user and there's no other solution on the market, the user will be willing to use a broken, incomplete product (this is always true when there's a real pain and no competition, which is why spending time building an app to validate a problem is wasted time).
- no-code: the prototype is never an app. usually it's something like a Google Form, a landing page made in Carrd, a whatsapp conversation. it has to be something you can put together in a single day.
- it converts: the final test of the prototype is that the person buys. a prototype that only validates interest (e.g., the user books a call with us or leaves their email) doesn't validate that there's a market for our solution. the only way to validate an idea is with $$.
example prototype: to validate that employees want their salary on demand, we buy a whatsapp number, start a conversation with each employee, and ask them to message us when they need an advance on their paycheck. for each transaction we charge $X. we measure how many conversations and how many transactions we get over a week or two.
3. validate: we go find potential customers and put the prototype in front of them.
example: in the case of the on-demand salary app, we look at how many conversions we get over X amount of time (never more than a couple of weeks). there's an informal, qualitative variable that's hard to capture: how much pull we feel from the market, how much people tell us this changes their life, how much they recommend us to people they know in those first weeks. it's hard to measure, but it's often what determines (along with a high number of successful transactions during the experiment) whether the prototype is a success.
4. scale: with the solution validated, and only when our manual way of running the prototype can't keep up, we can start building a solution that lets us scale. this is the step I struggle with most, and I usually spend a long time in step 3. the risk of staying too long in step 3, especially with a team in place, is that people get used to doing things that way and lose sight of the fact that we were always testing a prototype, and that the manual work isn't the final solution. knowing when it's time to start scaling a solution is something I still haven't cracked. my first instinct is that it should kick in after a certain number X of validations (it can't be after the first one, because the first might be an outlier). another signal could be when the team running the prototype manually is on the verge of burnout. that's a sign the prototype has gone on too long. another approach I think works is putting an end date on the prototype. the date is always arbitrary and I don't think it really matters. what matters is that once the prototype is validated, you have to start building a solution (maybe the hard part is identifying when something is actually validated?).
the difference between validation and product-market fit
lately I keep thinking about how irrelevant the concept of product-market fit is. my conclusion is that every product has a market willing to buy, but usually the real problems are different: not knowing what that market is; knowing the market but not having access to it; the market being too small; there being too many identical solutions in that same market, where ours can't compete because of weak positioning, etc.
I think we use the idea of PMF to talk about solutions with paying customers who love the product, recommend it, don't churn, etc. as I write that, I think: the idea is fine and I'm glad it exists, but it has a magical quality to it that I wish it didn't have, and that makes it feel less concrete.
I think the idea of validating a product against a market is more concrete and more binary: a product either has a buyer or it doesn't, and a buyer is only willing to use an incomplete solution when they genuinely have a problem with no better solution. the upside is that if validation does happen, it means we have a product, we found a customer willing to pay, and we're effectively their monopoly. that's the best of both worlds.
something to note here is that our validation process doesn't validate "product-market" fit, but rather "product-customer" fit, because our validation only tells us this product is necessary for a specific customer, who responds to a specific message at a specific price. if any of those variables changes, the process starts over.
that's why a product that worked perfectly for one ICP can completely fail to work for another. that doesn't mean the product doesn't have PMF, it just means it might not have fit for that particular customer. an ICP change, like a product change, takes you back to zero in the validation process, and it requires the same effort as starting a new startup.
my intuition from this is that the PMF/validation process never ends. every new feature, every new market we want to expand into, every change in positioning requires the same work as starting from a brand new idea, because our "PMF" only validated a different, earlier set of assumptions.