keyserfaty

my biggest takeaway from selling b2b lately is that the only thing that matters is figuring out whether an account needs our solution now, in the long term, or never. two notes on that: for a long time I sorted accounts into qualified and not qualified. I think it's important to subdivide qualified into the ones that need this product now and the ones that don't. the second is that to identify this, I had to get better at the questions I ask, and unconsciously my process has become trying to get to the no. I want to describe what I do that I think works.

why focus on the accounts that need a solution now

a few reasons:

1) value vs. effort. our product is hard to put a price on, but that's not the case for every b2b product. because it's hard to price, an account that brings in $200 takes the same work as one that brings in $10,000. I'd rather spend that effort on an account that has urgency now. it gives us focus, it gives us speed, and it lets us close more.

2) no pipeline BS. it's easy to lie to yourself in sales and assume every account that expresses interest or has a problem is going to become a customer. one way to avoid that self-bullshit is to only focus on accounts that need to solve a problem now. I don't think "creating the need" exists in b2b sales. accounts either have a pain or they don't. if they do, what matters is understanding budget, timeline, and decision maker. if we have those 3 (and the timeline is now), we have a much better chance of closing.

3) it creates buzz on the team. closing matters. closing zero accounts in a month is not the same as closing 3 or 10. it doesn't matter if they're big or small. bringing in customers creates a sense of urgency, and not bringing in customers makes the team feel comfortable and calm. focusing on the accounts that need this now matters because it brings in customers, and that brings motion and urgency to the team.

getting to no: what I ask to avoid my self-bullshit

writing this out, I realize I do all this to avoid my own self-bullshit that an account is going to close when it might not. some of the things I do to get to the no:

1) my first question is "why are we here". the goal of this question is to get the other person to share their pain or need. some people are clear about it, some aren't. a good answer might be "I have X problem with my team and I think this can solve it" or "I have X metric that came in bad and I need to improve it". on the flip side, not having a concrete answer doesn't mean there's no pain. it just means you have to dig a little for it to surface.

2) the only thing that matters in the first call is finding a pain. do they have a situation to solve? a metric they need to fix? a team asking for something? a manager who actually wants to solve this? or are they just shopping around? that's the only thing that matters. most people don't waste their time on a call if they don't have a concrete problem, but often they won't come out and say it. let's assume that if they have a problem, they want to solve it.

3) I give them all the info on the first call. my goal is to get them to say things like: this product isn't for me, it's too expensive, it doesn't solve X problem I have, it's not for X kind of company. I give them all the info on the first call because I want to reach those sentences as soon as possible. if I save the demo or pricing for call 2 or 3, I might find out on call 3 that this company could never have paid for this solution. I need to know as soon as possible so I don't waste time on this account. if they still want to keep talking after seeing everything, that's a great sign.

4) I'm looking for them to tell me they don't want to talk again. if everything went well, there's a pain, I gave them prices, I showed them the product, and I propose talking again in 2 or 3 days to go through more details, I want them to say no if there's no real need. if there's a real need and urgency, they'll ask for more detail and another call themselves. saying yes to another meeting after seeing everything is a good sign.

5) I'm looking for whether they want to talk pricing and implementation details. beyond the general pricing I can give in a first conversation, if the account has something real to solve, they're going to want to know implementation details. that's because they're starting to picture what this looks like inside their team. after every call I always try to book the next one, and a strong signal that the account doesn't have urgency is not wanting to book that meeting. especially when selling in latam, where talking about pricing carries more weight than in the US, proposing a call to walk through pricing in detail is helping them say no. if they say yes, that's a good sign.

6) overall summary: I want the account to tell me they want to move forward, instead of me pushing them forward. this week I had an account that gave me a verbal yes. instead of just sending the contract, I asked them: do you want me to send the contract over? there are two possible answers: "hold on, I have to talk to X to nail down X, I'll let you know" or "yes please". it's a tiny example of what I'm testing. even after they say yes, I want to know whether it's for now or for later. if it's urgent, the answer is yes. if they're thinking about implementing this in 3 to 6 months, they'll push it out (and if so, I want to know as soon as possible).

some disclaimers about my method: 1) we have a lot of qualified leads and we can afford to filter this aggressively. not every industry is like that. sometimes leads are few, and qualified ones are even fewer. 2) our product can be sold quickly when the interests are aligned. some products need a sales cycle of months because of the product itself. that's not us. 3) it's very important to balance this with a strong desire to close these accounts. it's easy to read this playbook the wrong way and end up closing nothing, or to look for excuses to let an account fall through. this only works because all I want is to close these accounts. I'm not focused on the no because I want to work less or work worse, I'm focused on it because I only want to prioritize the ones that will close fast.

- don't advance opportunities in the pipeline that don't have a current pain. I think qualified calls split into two buckets: in pain now, not in pain. the IPNs are the only ones we should pursue. the others should go to long-term (for lack of a better category). we often confuse companies that fit our target with companies that actually have a real need. I think the key is finding signals in the first meeting that the company needs to solve this problem now. in my experience, that means asking whether they want a more detailed proposal to make a decision, and getting them to schedule a second meeting. the company without a real need will say no; the one that has the need will ask for the proposal themselves.

- co-creating with the champion matters because it builds trust. one thing I figured out is that we can accidentally rush accounts. we want to rush them to improve our deal velocity, but that goes against what the person on the other side wants. in my experience, you need at least 3 meetings with latam counterparts to build that trust. you can see it in 1) them agreeing to another meeting, and 2) them sharing more about their pain in each subsequent meeting. trust isn't built just by holding meetings, it's built by co-creating. that can be co-creating the proposal, or co-creating the presentation to the decision maker.

- when you're selling to someone who isn't the decision maker, there's always a moment that's a black box. our product is for heads of people. heads of people need to validate the budget with finance or with the CEO. even if we walk that process with them from the start and have built trust along the way, there's a moment that's a black box: when they present to the decision maker. there are things we can do before that point to support them, but in the end it's on their side. I still have to learn how to support the champion more at this stage, or how to make this stop being a black box.

other lessons unrelated to the sales cycle

1) I learned a huge amount about how to sell this product by interviewing candidates. I learned something from everyone, even from people who weren't a good fit. the questions they asked, their presentations, their tactics for booking a follow-up call. I also learned a lot from watching, from the outside, how I think you shouldn't sell a b2b product. the high-level takeaway is that I always learn a lot from "interviewing", even when it isn't specifically for hiring. having conversations with people who are better than me always teaches me things I can apply almost instantly.

2) when sales calls start to repeat and every client says exactly the same thing, has exactly the same pain, wants the same next step, you have product-market fit. I had the same feeling when we were selling b2c: after the 10th call, every call was identical. same pain, same profile, same urgency. seeing a repeatable process is the signal that you have a product with PMF (think about it in reverse: how brutal would it be if every call was different, wanted a different product, or wanted a different next step).

building a startup that survives is so hard that I think we sometimes pick ideas more for viability than for love. since any successful startup takes 10 years, here are some big problems to work on for the next 10.

- spaceships/rockets. if this isn't the first one on the list, I have my priorities backwards. probably not for me, but what fun.

- personal robots. robots that keep you company, that solve things, but mostly that are company. cubix robots for everyone: https://en.wikipedia.org/wiki/Cubix.

- ai something. for some reason, the ways of applying ai to b2c feel more boring to me than b2b. the personal assistant with Scarlett Johansson's voice doesn't interest me. but if I think about complex problems, more "piping" problems, that can be solved with ai, I'm much more interested. (I'm thinking: integration problems, interconnection problems, systems talking to each other.)

- startup infrastructure for latam. this one is fun because I know how complex it is to run a startup in latam. some assumptions: 1) starting a startup in the US is much easier than in latam, 2) to build a startup in latam, you have to build it for all of latam (you can't do a single country, unless that country is brazil), 3) latam has operational complexities the US doesn't when you want to build in the region (payments across countries, legal entities, different regulations). the ideal startup in this space would help with payment processing (stripe for latam) and legal setup. it's the path yuno, pomelo, and others are taking. what I'm aiming at: a structure for building companies that makes it as easy to build in latam as it is in the US.

- ai for government. I think the future of governments is a model trained on the country's information that tells us what the next step should be.

- something something transportation something something. flying skateboards? flying with thrusters? flying cars?

- smart furniture. smart electronic devices.

- gpus. how can we build gpus (or whatever comes next) with natural resources that aren't the ones we use today?

if you only read one thing from this post, read this: some people work slowly because they think they have to put the same effort into every item on their to-do list. I think working smart is knowing which items on my list determine the success of my project and which don't. that's it. the rest is more thoughts on speed.

I'm writing this because I often tell my team I want us to be faster, and I can tell it isn't landing. these are some of the things I think they hear when I ask them to be faster: 1) this person doesn't understand how hard what I'm working on is, 2) I can't go faster because I'll do it badly, 3) if I do it badly or imperfectly it means I work badly, 4) the way to work well is to obsess over the quality of what I do, 5) this person is asking me to do something halfway, 6) this person is asking me to work after hours so we can have this sooner.

none of those things are true. I want to write about this partly because I want to think through what speed actually means to me and why something that's counterintuitive to a lot of people feels so natural to me.

(I think I should write about why speed matters, but instead I'm going to link to when I wrote about why I think it matters to ship imperfect things. it's another way of talking about the same thing.)

why I think people are sometimes slow

1) they don't know that speed matters. my guess is that no one ever told them speed matters. probably because they come from work environments with a different pace, or because in latam there's no sense of urgency in the startup world. this week I told someone on my team they needed to solve something faster, and they said it worried them that I was asking, because it made them wonder if we were running out of money or if the company was doing badly. that read is completely reasonable, because in the latam startup ecosystem there isn't a sense of urgency. there's nobody else doing what you're doing (or building better products, or shipping features faster). we don't watch what others do. competing is kind of frowned upon (at least in Argentina). on top of that, by definition a startup is always running out of time. that alone should be enough.

2) they think every item on their to-do list has the same importance. I'll give an example: I'm trying to close a sale. closing a sale involves several steps: putting together a presentation, building an ROI, booking and prepping meetings, drafting proposals. if I think every item on this list has the same importance, I'll put the same energy into all of them. but the design of the presentation, for example, doesn't matter as much as building the ROI. one problem I see is that some people think they have to put the same effort into everything they do. I'm 100% in favor of perfectionism, but we should only be perfect about the things that matter. working smart is knowing which items on the list determine the success of the project and which don't. it's important not to give the same attention to everything, and important to develop the intuition for what matters and what doesn't.

3) they work with inefficient tools or systems. this is easier to understand when we're talking about engineering, but I think the same applies to badly designed processes. if a task takes twice as long because it eats up so much mental energy, I'm going to be slow. in code, it's easy to spot when this is happening: it's the moments when an engineer has to do a task and spends half the time deciding whether to just do it or rewrite the whole thing. in those cases it's often better to fix the system at the root so we gain speed later.

4) they don't trim, they do everything on their to-do list. years ago I was taught a system called get shit done, which says that for every task the first question is whether I can delegate it (if I can, I do); if not, can I do it in less than 5 minutes (if so, do it now); if not, schedule it; and if I can't schedule it, I have to delete it from the list, because it means I'm never going to do it. part of being fast is deleting items from the list. it's important to trim ruthlessly and trust that if something matters, it'll come back.

5) they don't break work into small units. a very common way to be slow is to waste time. and wasting time is often working on things that aren't important right now. when we look at a big project, we tend to start with the part that feels hardest. it's very important to do the opposite: start with the smallest, easiest, fastest unit to complete. that matters because a finished task gives you the energy to take on the next one. instead of starting with the big and hard, start with the small and easy (the low-hanging fruit). the other thing that matters is breaking the work into small, doable chunks. and it's important to sort them from smallest to largest (by how long they'll take) and start one at a time.

6) they think something well done is something that took a long time. I think the opposite is true: something that took a long time is often something we built under assumptions that may have been wrong. the problem with taking a long time to finish something is that we're flying blind. we won't get feedback until we have the final product. and if the final product took 3 months, it may mean we spent 3 months building on faulty assumptions. another way to think about speed is that what we're really doing is sharing our process. there's some ego in wanting to share only the finished product (we don't want to be criticized for something incomplete). it's important to work past that, because it costs you time (and it's mostly imagined: nothing lands better than the vulnerability of showing someone an incomplete product and asking for help building it).

7) they solve problems they think they'll have in the future, instead of problems they have now. the important question here is how many users we're actually going to have over the next 6 months. usually the business-side roles have an estimate. if it's a b2b business, we know the monthly growth target is 20% and that means X users a month. you build a system for that number of users. again, this is easier to think about in engineering. a tell that a dev has this problem is when they keep talking about "scaling" and justify their decisions with scale. things justified with "scale": complex queueing systems, notifications, measurement infra. obviously the line is thin between when these things matter and when they don't. that's why it's important to understand the actual usage of what you're building.

now that I've listed what I think makes people slow, I could list what makes us faster. to follow my own advice, I'm not going to. this post as it stands is more useful now than it would be after another 3 days of work. I hope it's useful as is. and I hope I'll keep learning so I can write more on this later.

hubspot is a frustrating tool. at atlas every team uses it, and now that I'm informally part of our sales team, I'm in it day to day.

hubspot rarely guesses what I want to do next. some of the things that get in my way:

- there's a Cmd + K for searching across the whole app, but it's slow. it can take 3 seconds to load after I type a query, which softens the point of having a shortcut (it's often faster to click the option in the left sidebar). search results don't usually surface what I'm looking for first. the order is Contacts, Companies, Deals. if I search for a company name (because I want to land on the company profile), I have to scroll past a list of contacts that belong to that company first, because that's the order results come in. if I search for a person by email, I get a list of everyone with a similar name. if the person doesn't exist, I usually want to create them, but creating is a separate flow.

- having to manually save changes can be confusing. in modern UIs built in the last few years, changes save as you edit. having to press "save" is harder than it sounds, mostly because it's not always clear what's in scope. does the save button apply to the whole screen or just the input I just touched? can I keep editing other things and it'll store them all, or only the first one I touched? and if I accidentally refresh the page, my changes are gone.

- configuring how the platform looks is less intuitive than I'd want. you have to go to Settings, and almost everything ends up being edited inside Objects. there isn't an obvious order in either Settings or Objects. usually I have to read the entire list of options to find what I'm after. when I can't, I end up googling how to do what I want.

- the workflows screen is one of the trickier parts of the product. to build an automation you have to start from an object, which surprised me (the pattern I was used to is starting from an event). I won't go deep here because I could write a whole post just on workflows.

at the same time, hubspot is also an incredibly powerful tool, for reasons that have nothing to do with the friction I just described. if someone were building a different CRM and asked us to try it on the team, we couldn't, and the reason is clear: hubspot is wired into our entire workflow (across 3 teams: marketing, sales, and CX). we can't "just try another CRM." the implementation cost would be enormous. that got me thinking about how someone who wanted to build something in this space would actually compete with hubspot. these are my hypotheses.

the things hubspot does well

start by understanding what makes it a good tool. I think it's these:

1) integrations across the rest of the stack (it integrates with performance tools like SEM and FB ads, with outbound tools like Apollo, with Gmail and other email providers, with Stripe and others).

2) it centralizes information across at least 3 areas: cx, mkt, and sales. it's the single source of truth for those 3 areas. they go to it to check metrics and track their work.

3) it ties marketing and sales together like nothing else: tools that are just good CRMs don't do this, and that complicates the sales cycle. when you can pool mkt and sales leads in one place, it's easier to run remarketing campaigns or understand the full lifecycle of an account. same thing when those accounts get handed off to CX for expansion. all the info lives in one place.

4) it's free. that's tricky for a startup. competing with a free product is hard because the alternative has to be meaningfully better for someone to pick it over the free, consolidated version.

where to start if you want to compete

the challenges of building a tool to compete with hubspot:

1) for an organization, switching has a huge cost. one way around that is to sell only to startups at first, and I think that's a naïve first approach and not a good idea (why: startups graduate off you; they need more things; "startup" can mean ten thousand different things).

2) for it to work, it has to integrate with your current stack from day zero. that's expensive because integrations are complex and slow. the hardest part is figuring out which integrations to start with. I have a strong take here: I think the wrong approach is "whatever users ask for" or copying the most popular hubspot integrations as they exist today.

how to compete with hubspot

first claim: at some point a tool will come along that rethinks this space. it's the natural cycle of any industry, and hubspot, compared to tools born in the last 5 years, has some shortcomings that today's users feel. someone will eventually build a tool that solves this problem 10x better with today's tech, and it'll take market share the same way hubspot took it from Salesforce.

the hard question is how that tool should start. the problem to solve is clear: how do you build a tool that's a better version of hubspot in the shortest time possible, while generating revenue from day zero? the challenge is the scarcity of time. to put it another way: what does a tool look like that you can build in 4 months or less and that can pull paying customers off hubspot from day 0?

my solution

1) pick a single segment. hubspot has many types of customers. different industries use the platform very differently (and hubspot has thousands of features). an ecommerce company uses it differently than a b2b saas. a b2b saas uses it differently than a b2b with usage-based pricing.

pick one of those segments and figure out which features are priority for that group. I'll pick one because examples make it easier: a b2b saas sales team only uses a few things:

- Integrations: linkedin ads yes. instagram ads no. gmail yes. outlook yes. google calendar yes. zoho no. intercom no. stripe yes.

- Features: sales pipeline yes, automations yes (but only one: you have to figure out which one. if I had to guess, I'd say the top one is updating a deal when different events fire).

there's something very important about picking one and only one segment: you have to be inflexible. we are not going to integrate with intercom. we are not going to integrate with zoho. we are not going to add the automations marketing wants.

focus has to be brutal and unapologetic. we only do that one thing. when do we stop only doing that thing? when we have a solution that's 10x better than hubspot's for that segment. that's step 2.

2) the second thing we have to do to win is have a solution that's 10x better than hubspot's, but only for that segment. what does 10x better mean? the tool has to guess what I need and what I'm going to do next. the only way to get to that level of product quality is to be the first users of the platform yourself (we have to be sales people in b2b saas to be users), and it's really important to obsess over solving the only problem this user has. what problem? closing deals. how can the experience of closing deals be 10x better than hubspot's? you obsess over that flow and only that flow. how do I know my solution is 10x better? users will tell you.

3) this game is only won with speed and revenue: none of it matters if I build something behind closed doors for 4 years only to find out it doesn't work. the variables to optimize for here are speed and revenue, and those are the only ones that matter. what features does a product need so people pay for it after 4 months of development is the only question I'm trying to answer. neither variable is negotiable, and here's why.

why I can't stretch the release timeline: first as a matter of survival (every startup is always running out of money), but also because a short development cycle gets us user feedback faster, which is the only way to end up with a good product. I've already written about why shipping incomplete things matters, but the short version is: you have to validate with users and build with their feedback.

why I can't offer the product for free: because at this stage what we're running is an experiment. the experiment is whether there's a business in this idea. that's the only experiment we're running. we're not testing whether users like our app, or whether they want to use it, or whether it solves a problem for them. the only thing we're trying to prove is that the problem is sharp enough, and the existing solution is far enough off, that users are willing to pay for ours. an mvp is an mvp of the business, not of the technology. what we're testing is willingness to pay and nothing else.

so: the two variables we can't touch are speed and revenue. that actually gives me a lot of peace, because it sets the playing field. every other variable is fair game. for example: instead of building an app, can I run a whatsapp group with my users where they tell me how their deals are going and I update an excel by hand? yes. (one extra challenge: this is an established industry and the product isn't category-defining, so janky solutions like that won't always work. the user expects a product, because they already know the category.)

how to keep going

once you have the product I described, the next step is to do the same thing for a second user group. in my case I'd go to marketing next, because the way the work of those two areas comes together is what makes it so important. but you can't leave the industry. it doesn't matter how many intercom messages I get telling me we have to add a Shopify integration. we only solve a problem for b2b saas (now for sales and for marketing).

this was a thought experiment for me. I'm writing it because I enjoyed thinking it through, and it made me reflect on where it overlaps and doesn't with the problem I work on today (which isn't this one). I'm sharing in case it's useful to someone else, and because all that matters is shipping, even when what you're shipping is text.

I've been thinking about the importance of incomplete ideas. in my work designing and building products, it's important to build things and ship them half-done. the ideas behind why we do that are two: 1) the only thing that matters is speed, and 2) it's a safety net against spending a long time on something nobody wants.

the one that matters most to me is the second: shipping a first version and building on top of feedback is better than shipping a finished product.

let's think about the upsides of half-built products to understand why:

1) incomplete products make people want to complain. anyone (from my mom to someone in our ICP) will have opinions about how to make something better when they see an ugly, unfinished product. they'll tell you, and they'll tell you with feeling. ugly things make us uncomfortable. we want to fix ugly. (in a world where honest feedback is hard to come by, that feels invaluable.)

2) incomplete products are an ego check. think about how a product gets built end to end. take Humane. their foundational story: lots of capital and 2-3 years of work behind closed doors. the problem with working behind closed doors is that there are no feedback loops. if the people building it lack self-criticism, they can put a product on the market that's useless to everyone, because none of the internal feedback loops ever told them "this product is awful and can't even do basic things." if Humane's strategy had been more like Rabbit's (same product but a hacker mindset: "we know this is rough, it's a beta, it's broken"), they'd have benefited from that feedback loop. I think the worst enemy of a good product is its founders' opinions.

incompleteness is uncomfortable. that discomfort comes from a few places. one is ego (what will people say about this being the product I made?). that discomfort is what makes us want to create. there's something instinctive that happens to a certain kind of person when they see something ugly: they want to fix it. fixing turns into creating, and creating turns into motion.

I sometimes hear people in the startup world frustrated with incompleteness. I don't get it, because I think a startup is an incomplete idea. the ideal person for a startup is someone who enjoys the discomfort of incompleteness.

with the same frame, I can think about other things: how a big corporation can feel static because there's no room for creation, and there's no room for creation because there's an illusion of completeness, of something already solved.

how being incomplete people is what keeps us in motion. we do and we create because of that. I know Lacan talks about this. I wish I could go deeper but I don't know the idea well. what I think he says is that desire lives in what we lack. that is: we desire (we act), we move, we aim toward, only because of what we don't have, not because of what we do. what guides desire isn't what we've done, it's what we haven't yet.

intuitively it makes sense: obviously I desire what I don't have. it's the core behavior of capitalism. I want what I don't have. because I don't have, I desire. and at the same time, how powerful is the idea that we live alongside lack. that the root of our doing isn't what we've done so far. it isn't the person we've become. it's the part with no answer. the harder part to point at. and obviously that desire doesn't always show up clearly (does it ever?). we end up understanding what we want by doing, and that doing makes us who we are. only there do we uncover something of ourselves, searching in what we lack for another piece of who we are.

I wrote about how we built a product with PMF at Atlas in an earlier post. lately I've been thinking about other ways of building products that have PMF, and I've come across other examples worth writing down.

sell before building product (the Atlas way). an MVP you can build in an afternoon (a Stripe link is enough when the pain is sharp) and sell subscriptions. only start building real product when volume gets high enough that solving things by hand stops scaling compared to solving them with tech. the problem with this approach is that it doesn't work for every industry (I'm thinking of products that are complex to build, like biotech or hardware), and over time I'm more and more convinced it's a brute-force approach when you have no idea who your customers are or where they are. I think there are better ways. more on this model here.

build a product inside another company (the spin-off way). the main problem with those of us who build product is that we often build product because we like it, even when nobody's willing to pay. the advantage of building a product inside a bigger company is that you're necessarily building for a customer (aka the company you're inside), and you can be sure the product is needed and that someone would pay for it.

(I'll share an example of an idea like this because I think it can help others think through whether an idea has PMF.)

at Atlas, teams always need more tech, and sometimes an idea comes up that I think could be a company on its own. I've been thinking a lot lately about one of those. my indicators that it would have PMF: 1) I understand the problem completely, and I know for a fact no solution exists because we already searched for it in the tools out there (so this product would be a "category-defining product"), 2) I know it's needed because our team needs it, and I've interviewed enough people in that role to know it's always a pain, 3) it's an industry that's ready for a refresh, and a tool like this would deliver it (better UX/UI than what's available; a different approach from existing solutions), 4) I know the first 20 customers of this company and I know they'd use it (I'd start with our current customers, the ones I already have a relationship with and trust), 5) I can describe the ICP of the first 100 customers exactly (engineer-founders with this problem at small companies of <100 employees, B2B, US-based), 6) I know it's a sticky product because it integrates with your whole current stack, 7) I know the team I'd be selling to has budget and is easy to sell to.

I think there's another approach, but I haven't fully cracked it yet: the Notion/Figma way. building something behind closed doors for years and coming out with a great product that does well. the issue with this approach is that everyone thinks they're Ivan from Notion or Dylan from Figma, when the truth is very few people ship product of that quality with zero user feedback. the question I keep asking, because I don't actually know, is whether those people really had no feedback or whether they were shipping small iterations along the way. with the info I have today, I think the only way to make this approach work is to know enough about an industry to be sure the product is necessary. if you're an expert in a problem, you can build something on the strength of what you know, and the solution will land. maybe the real question is whether the people who use this approach are absolute experts in their problem. going by my experience with Palabra (my startup without PMF), the answer is no. I wasn't an expert in that problem. I needed feedback to build a better product.

be an absolute expert in a problem and build behind closed doors (the Notion way). like I said, this approach only works if you're an expert in a problem and you're also an incredible executor. I'm not willing to bet on it, because I've seen it go wrong many more times than I've seen it go right (I'm thinking of Humane and the product they launched recently). I want to keep thinking about this option, but if I were a founder without experience, I'd definitely go with one of the first two.

TL;DR: we look for two things: technical excellence and agency. in interviews we push on what the candidate knows to find out how far it goes. we hire people who are better than us.

I'm writing this because I think I've gotten better at finding good talent in this hiring round, and I want to share what I did. I want to cover two things: 1) how we think about hiring at Atlas, and 2) how we actually find the best talent.

how we hire

the people we hire while we're still under 30 will shape the culture of Atlas for years. good hires save us time because they have autonomy and help us grow. and good hires mean working with brilliant people who push us forward and make us better, and that's a real luxury. for all of those reasons, we have to learn to hire well.

what an ideal candidate for Atlas looks like:

- has autonomy, ownership, agency. makes proposals, asks for what they need, suggests changes.

- has technical expertise. top 1% of everyone we interview.

- is better than us. that means: more years of experience; career milestones that are more complex than the ones we've hit in this role; makes us a little nervous to bring on, because they clearly know more than we do.

how we find the best talent

even when we agree we want people with autonomy and ownership, it's hard to actually spot one. I'll share the method I used in my last hiring round to identify high-agency people.

some general principles:

- we run a consistent interview process. ideally, keep a spreadsheet of the questions we ask each candidate and save the answers, so we can be objective and compare.

- we always look for 2 things: technical excellence and agency. we measure technical excellence through their experience leading complex projects. we measure agency by asking about projects they've proposed in their current jobs.

- we keep digging on each question to find out how far the candidate can go. we don't stop at the first answer.

what technical excellence is

- they have to know their area inside out.

- they have examples of complex projects they've built.

- usually 5 to 8 years of experience in the area.

- top 1% of the candidates we interview.

how to identify technical excellence

- the way to spot it is by asking about something they did in a previous job. I like the question what's the most complex technical challenge you've had to solve (for non-dev roles, it can just be "the most complex thing"). for me, this question is an excuse to dig into that project in depth.

what I look for in the answer:

- they can talk in real detail about the process, the tasks, the tools, the challenges of what they had to do. a red flag: not going into detail, not naming any tools, staying very general.

- they can communicate what they did. it matters that they can walk through their work and their role in it clearly. if they can't, they're someone who's going to communicate just as poorly day to day at work. red flags: jumping between several challenges without committing to one in depth; vague explanations; it staying unclear what they actually did.

- their level of involvement. we want people who led or worked closely on the project they're describing. we don't want someone who worked on a small slice or just took instructions. red flags: not being able to talk about the project in detail usually means they didn't make the decisions. they have to be able to explain why the choices were made.

- the project was actually challenging. for devs, examples of non-challenging projects: consuming an API; setting up a service in AWS; I'd look hard at blockchain and crypto projects that often hide simplicity behind complex language. for paid marketing roles, examples of non-complex projects: products that sell themselves (e.g., ecommerce); projects with infinite budget; projects with goals like "drive traffic"; only having run campaigns in places like Argentina where it's much less competitive.

- how they handle follow-up questions. my usual move is to ask the question, listen to the answer, then paraphrase what they said back to check I got the project right. from there, I ask "why" a lot, both to understand all the points above and to find the edge of what they actually know. people who don't know their stuff well usually struggle with these follow-ups, and it's normal for them to get defensive. it's important to see, because it's how this person would behave under pushback or disagreement at work.

what agency is

- takes responsibility for the area they own.

- proposes things, makes changes without asking, digs deep into the context of what they're working on because that context is what their decisions run on.

- has opinions; says what they need.

- has ideas about what they want to happen and usually just executes them.

- action-oriented. doesn't complain.

- manages their time well. plans their own work.

how to identify agency

- I like asking about a project they've proposed at their current job (whether or not it actually got done). the reason I ask is that people who propose ALWAYS propose. it doesn't depend on context, job, role, or area. if they don't have examples to share, it's a no.

what I look for in the answer:

- it's a project with business impact, not "tooling". examples of bad proposals: for sales, suggesting using a CRM. for devs, suggesting a refactor or a new library. for marketing, suggesting a tool, CRM, migration, etc. what's a good answer: a project that generated revenue or cut costs; a product or business idea.

- they can talk about whether it worked or not, and they use metrics when they do. if they don't talk about metrics, it means they're going on intuition, and that can be a problem.

- creativity: something that catches my interest, that's exciting to hear, that makes me think "wow, how did I not think of that".

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.

- we don't build product unless we have a customer willing to pay. we always need to know whether a feature or product is in validation mode or growth mode. if it's in validation mode, we don't do growth-mode things (like hiring, investing in ads, setting up rigid processes).

- we don't scale experiments, we only scale validated processes. that means not spending money, not building product, not hiring, not buying things (software), not investing in ads (at scale; small-scale ads to validate are fine) until a process is validated.

- we make decisions fast. for decisions that don't have long-term impact, we pick something and move forward. those decisions are often essentially random. that's fine. what matters is taking action, validating against reality, and if the decision was bad, making another decision just as fast to reverse it. we don't do analysis paralysis.

- we move fast. we constantly look for where we (and the organization) are being slow. we unblock bottlenecks. we execute fast. perfection doesn't matter. speed matters.

- for decisions with long-term impact, impact on people, impact on the whole organization, or legal impact, we examine our assumptions before acting: can we validate it with numbers? can we validate it with customers / willingness to buy? nothing should take us more than a week to decide.

- we own the details. we can speak to the details of the areas we lead, and we own every decision made in that area. we don't have a hands-off leadership style. we're in the day to day and in the detail. we like extreme ownership. to ask the team for it, we have to practice it ourselves first.

- we hire slow and we fire fast. our interview process has to be exhaustive because we're looking for technical excellence and cultural fit. we can't delegate hiring for now. it's important that we run it ourselves and that we interview everyone who joins at least once. we always hire people who are better than us; people we feel a little uncomfortable hiring because they're better at our jobs than we are; people we'd be proud to introduce as part of our team. on firing fast: it's important to be transparent with people, say what we think, set action items and deadlines. from the first time we think someone isn't working out to the moment we activate an action plan, no more than a couple of days should pass.

- we are fair. we make decisions with people in mind. if we can help, coach, share more information, or support someone, we do. when in doubt, and the action has no negative impact on the company but has a positive impact on the person, we do it.

- we are transparent and not bureaucratic. we tear down bureaucracy as it appears. if someone needs something from someone, they go and ask (we avoid person -> leader -> person triangulation. the ideal is person -> person). bureaucracy and hidden information slow us down. all that matters is speed.

- we give feedback fast and in the moment. we build a culture of saying what we think the moment we think it. friction shows up when we think things we don't say. we give honest feedback to each other and to the teams we lead. the only way to win as a startup is to have an A-team, and the only way to have an A-team is constant feedback (because it's the only way to improve).

- ideas don't matter. a startup is an experiment. no idea matters, and it doesn't matter who it comes from. all our energy has to go into validating ideas (and the only way to validate is with willingness to pay). anyone who puts their ego ahead of validating ideas wastes our time and slows us down.

- beauty matters and quality matters. we don't imitate, we don't copy. we know what the competition is doing better than anyone, but our execution is 100x better. we come up with new ideas, we're creative, we improve what's out there. we push our industry and our customers forward with innovation and quality whether or not customers or the industry are asking for it. our north star is excellence, not what others are doing.

- we work on big, important problems. Hamming question.