keyserfaty

if I try to think back to how I started Atlas (or Palabra, before that), I don't remember the state of mind I'm in now. I didn't start out thinking I'd build a 1B business. the first time I heard I had to put together a plan for 100M in annual revenue it sounded ridiculous to me. I didn't dream of raising vc. I couldn't picture what the next 5 years of my life would look like. but I also never doubted I'd want to keep going. my only north star was making a product I'd be proud of. my dream product.

I try to look at myself with the eyes I have now. would I have invested in karen? would I have seen the person I'd become 5 years later? would I have written her off as inexperienced? would I have read that as a lack of ambition?

when I talk to latam founders I'm sometimes struck by how they see their businesses: the focus on EBITDA, not thinking about going regional, sticking stubbornly to small markets or not even knowing the size of their market. my co-founder and I coined a term for it: "smbs with tech." they don't behave like startups. they don't think about growth. or they think about growth the way any smb founder would: sell until the business sustains itself, then sell some more so you can pay yourself a little better.

I try to imagine what I believed 5 years ago, and I wasn't any different from them. I didn't know the size of my market and I didn't know how to sell. Palabra died because I cared more about the product than about product-market fit. and if I wasn't dreaming about a positive ebitda and selling only into argentina, it was because of the people around me.

I didn't know any founders in argentina. while I was building Palabra from my living room in Caballito, the other founders I talked to were in SF. I learned and listened by working with people I admired. Daniel Gross invested in Palabra when we were nothing, and if I learned to think about the business like someone from SF, it was from blindly listening to someone I respected.

does that mean ambition feeds itself? my ambition wasn't fed only by the people around me and their giant dreams, but also by the sense that it was actually possible. when we started, Atlas felt inevitable. we were selling more than we could keep up with. our calendars were packed monday to monday with calls that converted into sales 50% of the time.

I think my ambition came from understanding the game, getting excited by the game, and also believing I could win it.

sometimes I look back on that period. one thing always surprises me: I was coming off a year and a half of building Palabra. we didn't have PMF, the last few months had been incredibly painful, and a month after shutting it down we started Atlas. it feels like years passed between those two moments but it was weeks. on one side, feeling awful. holding together a team that changed focus every week because we didn't know what to sell, watching the bank account run down, not knowing what to do. and then Atlas. all the energy of the early days. working hundreds of hours a day because we couldn't keep up. selling from day zero. having a ton of fun.

what changed so much from one week to the next? PMF feeds you, but more than anything it's the ambition for everything it could become. we started dreaming about building the next Deel because it felt possible.

one last footnote: that's why SF works. when you put the most ambitious people in the world in one place, they feed off each other. could they have done it somewhere else? maybe. maybe not.

i’m slow at learning. i invest a lot of time learning the fundamentals of a problem. to come up with solutions i need to understand the fundamentals first. one example: it took me 6 months to understand the strategy behind our Card product after initially coming up with the idea.

once i do understand the fundamentals though i’m 10x better than most product people. i don’t spend time copying what others are doing. i have a clear vision of the path we need to take to get from 0 to 100.

i’m slow at hiring. this is something i need to correct immediately. i keep C-players on the team longer than i should because i don’t spend enough time interviewing and meeting candidates.

i don’t assess risks. i rarely think about ‘what happens if this goes wrong’. i’ve learned that most of the time that’s actually a good thing but there are exceptions. examples are: decisions with long-term consequences or legal risks. since this has been an issue in the past i now try to ‘exploit’ my ideas when i come up with them. i still need to force myself to do it.

i give direct feedback. that’s probably not the bad trait: the bad trait is i do it often and i’m not too concerned with my tone or how i come across. this is also another thing i need to fix asap. i’ve learned that many times my tone matters more than the content of what i’m saying.

this might appear to be the most efficient way to solve a problem, but I will argue that in a human-centered economy we still need humans to process and understand information. i’d like to explore how AI tools can help us accomplish that, and how that might change in an ai-centered economy over the next few decades.

how do we think?

understanding problems and coming up with original solutions is something i’ve always cared about. i’m not very good at thinking off the top of my head so, with time, i’ve come up with some strategies to force myself into thinking and understanding. these are some of those strategies:

1) talking to others. an open discussion clarifies ideas and understanding and creates new ideas. sometimes called “brainstorming.”

2) writing it down on a whiteboard. i’ve always found this much better than writing on paper. it’s something about the ability to see everything at once that helps me understand problems more easily. 

3) making word maps. I remember, ages ago, trying to explain to someone how to think about a problem, and working with them on a word map to come to common ground. it's amazing how word maps can really trigger new ideas and lead us to new conclusions that we didn’t start with. i’ve always found it hard to think a couple of steps ahead, and mental maps really seem to help. 

4) writing/typing. starting with a clue and just letting the mind drift. I usually understand problems just by describing them and writing them down.

so how has AI been helping me come up with new ideas? by discussing ideas aloud, for sure. (talk mode is really an amazing tool.) but there is always a risk (at least for me). discussing a problem with AI means it will automatically try to give you the solution. and the thing with solutions that are given to us, is that we don’t fully process how we got there and so we don’t truly “buy” the solution.

think about times when you discuss a problem you are having with a partner, and they jump into solution mode. the frustrating part about that is that discussing the problem (complaining, ranting) is what's actually valuable about the exchange and not the solution itself. the act of talking about the problem is how we understand it and process it.

what does this mean for people that use AI as a replacement for their own thinking? my guess is that it means that they won’t be able to process and understand problems, and I argue that we need them to do that. (even if just letting AI give us the solution is more efficient.)

why do we need humans if AI can do it much better?

my reasoning is simple: we live in human-centered economies and democracies, meaning that the economic and political systems operate thanks to humans. it’s a human responsibility to make the final call on a policy. it’s a human’s work, and the salary they get for that job that moves the economy forward. in our current society, humans are the center of all systems, the decision-makers, and those responsible for how other humans live.

when the politician asks the AI how to work on a particular problem, without fully understanding its implications and only comprehending what the AI is saying at a superficial level, we risk harm to how other humans live. another way to think about that is that it is the AI that is understanding the problem (if so) and making the decision for the human.

one could argue that this is not an issue. if an LLM can process more content than a human and come up with a better solution than we can, we should use that tool. and I fully agree, but the thing is that LLMs are not there yet and are by no means deterministic thinkers that compare all possible outcomes before they propose a solution. until they do, we need humans to think, understand, and argue against ai.

the challenges of working out problems with ai

so, if we really need humans to think through problems, we need to come up with ways to collaborate with AI more efficiently. 

these should not be ways to make the LLM more efficient (although that is always a good thing) but ways in which we can train our personal models to work for us.

here are some of the challenges I see today when it comes to working out problems with ai—and some possible solutions:

1) AI jumping to solutions. this is the problem I stated originally. when the AI gives us the full solution to a problem, it’s hard for us to come up with a true understanding of the problem. something i’d like to test would be to give instructions to the model I use the most (sonnet 4, as of today) so that when I propose a problem it should never give me a solution but give me questions so I can keep thinking about it. if it does, it should never be just one but a series of solutions, forcing me to choose. 

2) AI writing a lengthy solution. one might think this is only a problem if people are not willing to read what the AI has written. but, as people say, the only good system is the one you use. we tend to not want to read all the content created by ai. a clear example of this comes with vibe coders. developers usually complain that the AI creates code prone to security issues. my counterargument to that is that it only does when you don’t read the code that it wrote. otherwise, you shouldn’t need to worry. my solution to this problem is obvious. train your model to answer in short answers or to write code in the minimal expression it can.

3) AI stating things as truths. from the days of gpt-3, we all seem to treat LLMs as prophets. the truth is that the LLMs we use are not giving us the most probable next word when answering a question but what the company that’s developing it has trained it to pick as an answer. in no way, even without that, would LLMs be deterministic thinkers. but the thing about humans and how we use LLMs is that we find it hard to challenge what the AI is suggesting, especially when it comes up with complete solutions (long texts, an ordered list, etc.). we are wired to believe that an answer stated with confidence shouldn’t be challenged.

my solution to this problem is that we should force AI to give us incomplete solutions. we need a way to force ourselves to think on our own about problems. my explanation as to why we need this comes from how the human mind works: our minds look for completeness, and what’s more interesting, they do so especially when they are faced with something that is incomplete. the mind wants to fill gaps.

for humans to really think about problems we need the AI to give us something we can iterate. think about mental maps. if I asked the AI to give me a full mental map (something like start from the word “poverty” and write all ramifications to how we could solve it), it would probably do a good job. but what’s rich about doing a mental map yourself is how, in the process, you come up with new ideas and explore them. 

what we need from the AI is the equivalent to writing down a mental map with missing words, incomplete paths, and empty cards for a person to fill out. we need that void, or incompleteness, to force ourselves into thinking.

what does an ai-economy look like?

i started by saying that while we live in human-centered economies we need humans thinking and understanding problems, and we went through some strategies we could use to use AI in a way that helps us accomplish that.

but what i’m really curious about is, what comes next? how do we move from a human-centered economy and political system to one that is able to delegate most of its work into systems much better than we are at understanding problems and processing large volumes of information?

what I could argue now is that this AI (whether it’s LLMs or something else) would need to become much better at coming up with deterministic solutions and that we need humans working out how to get AI to that next level.

what that AI economy might look like seems like a theme for another essay, so let’s just leave it at that.

the aeropress is an american invention. I'm not going to google it, I have no doubt about it. it's a plastic tube that sits on top of your cup and lets you make coffee for one. no doubt about it. the ritual of the aeropress is what I like most. weighing and grinding the beans. heating the water to 95 degrees. filling the aeropress with 255 grams of water and waiting 3 minutes.

I found a list of startup ideas I wrote in 2019 when I was choosing the idea for palabra.

there are a lot of ideas here that I find fun (some already exist) but my sense is that back then I wouldn't have known how to validate the business model for these startups, and today maybe I would.

I'd like to do the exercise of thinking through how I'd validate PMF for each one.

Webapp to let people rent a desk on a house to use as a co-working space

this one is complex because it's a marketplace, and the hard part of a marketplace is that it has two sides and you have to take care of both: build supply and build demand.

the first thing I'd do is validate the supply side. are there people willing to rent out their desks? is there any regulation around this (I imagine not)? but I'd validate that it's something legally allowed (or at least that it's not banned).

I'm also curious about pricing. on the demand side, how much would someone be willing to pay? I'd validate this against the cost of a traditional co-working and see if it makes sense (does it end up costing the same, or more?).

assuming none of those points raise a red flag, my first goal would be to land a single booking. for that I'd need at least one person willing to rent out a nicely set-up space. I'd take very good photos of it. I'd build a simple site (something I can put together with cursor/composer in 1-2 hours) that mimics a marketplace but where the only desk available is that one. I'd run ads on IG (probably reels) and measure conversions to the site and booking requests. my goal would be 1 booking.

if a booking happens, I could say the demand side is validated. I assume the next steps would be analyzing the competition and pricing in more detail. I don't have a clear sense of the economics of an Airbnb-style model but I'd dig into it and try to draft a first cost/revenue estimate to understand which pricing makes sense and which doesn't, and especially how much I can afford to spend on marketing.

if all of that goes well, I'd keep building supply and pushing harder on demand with reels ads.

App that lets people upload a short podcast on any topic

I find this one interesting because it's something I'd want to exist, but I'm not sure how I'd start. I like the idea because it's a TikTok for audio. I wonder if there's a minimal version of this, or something people already do that resembles it. for example: I think I could start by grabbing good podcast episodes, cutting them down, and keeping just 1 or 2 minutes of the best content. I'd want to avoid having to build an app to validate it because there's some unavoidable dev time (though much less than there used to be).

I'd rather focus on the quality of the content. I wonder if I could validate it by sending these short podcasts as audio messages on whatsapp and measuring the reactions of people I know.

another option could be, instead of building a mobile app, to build a simple site that works really well on mobile with an interaction similar to tiktok (scroll up and down to go to the previous/next one).

if I built that site I could focus on distribution. selling b2c is something I find a bit elusive but I have some intuitions: 1) I'd lean on the distribution of another platform (like tiktok and twitter). I'd share the content there to drive traffic to the app. 2) I'd remove barriers to entry (you can listen and share without signing up). 3) from day zero I'd build sharing mechanisms (you can share clips as whatsapp audios; at the end of every audio, a line saying you can hear more of these mini podcasts at "www.something").

the success metric here would be visits to the site and number of shares. I'd also measure whether people come back.

there's something about this idea I haven't unlocked yet: why someone would actually use it. is it entertainment? a replacement for tiktok? it kind of sounds like one of those ideas that sound good but that we wouldn't actually use.

app to pay someone to teach you something

this is one of the easy ones. marketplace again. the concept is "I want to learn X, who'll teach me." I'd post hundreds of requests like this (here you can fake the supply side) and validate whether there are people willing to bid an amount of money to teach it. I'd run social media ads again, or use twitter or twitter ads. success would be people bidding.

after that I'd validate the supply side. if the previous step worked, I should have user flow in the app. from day zero I'd include the option to post requests. the success metric that would make me commit more time to this idea would be 1 request from a real person matched with 1 offer from a real person.

I'd do the same as in the first idea to validate competition, pricing, etc. for anything that involves coding I'd take shortcuts. I wouldn't implement login, payments, etc. until the model is well validated. I'd handle everything with forms and manually until that happens.

this feels like one of those low-substance ideas that I don't think could grow into something big. but I could be wrong.

mobile app for motivation for female entrepreneurs

I get why past-karen had this idea, but I think this is more of a community than a business.

app to keep track of someone else's tasks

I think I had an interesting insight when I came up with this idea but today I'd say the solution is Linear.

display list of new features of a release to integrate into a site

I like this one. there are already some solutions out there. it's a small product and would be a good idea for a bootstrapped app. I think it's one of those apps that used to be huge efforts but today are easy to build. the mvp would be a form where you upload a list of features and bug fixes, plus a <script> tag you can copy/paste into an app to render the list (in a dropdown, in a notification, or as a plain list). building this mvp shouldn't take more than a week.

thinking about distribution, my first instinct is SEO. this is b2b after all and the target user is probably a tech lead or a PM who wants to show this in their app. before starting, I'd probably take a step back and talk to those people. I know some companies use apps like these to show their changelog but I don't have clarity on what stage they're at when they start needing it, or if they share anything in common. for example: do b2c companies tend more to want to show feature lists? is there some b2b industry that values dev velocity more and wants to show this off? is there something broken about the current process of sharing a changelog?

I can imagine (because I live it every day) that the changelog is something that takes work to put together. could it be simplified somehow? for example, taking the list of recent commits, parsing them with AI, and generating the changelog from that?

I also don't have clarity on who'd buy this product. I think it's a TL or a PM but I'm not sure. what's the incentive to want a changelog? what problem does that person have that a changelog solves? visibility with customers or with the internal team? pressuring the team to ship more often?

I wouldn't write any code until this is clear, because the solution can look very different depending on the answer.

another angle to investigate would be reviewing the current competition. tools like this already exist and they must solve a clear pain. it's probably stated on their landing page. what is it? does validating it with a PM or TL confirm it's a pain for them?

tool to integrate notifications to sites

this idea could go in many directions. what kind of notifications? in apps or on websites? I'm not going to explore it because I don't have clarity on what past-karen meant.

tool to allow anyone to create an online course

I'm not going to explore it because it's a bad idea. thousands of these were born in 2020, they all died, and now we have LLMs.

job board for education

I'm not sure what this idea is about.

app that lets entrepreneurs manage their finances when they are just getting started

I like this idea, and I'll say why: it's specific. I think there's a bigger idea behind it (is it finance for entrepreneurs in general? is it a simple finance app that starts with entrepreneurs and then expands to other audiences?).

I'd start by listing specific problems that entrepreneurs have with their finances, and I think there are many sub-niches to focus on. for example, Latam entrepreneurs in the US on a work visa. that group has very specific pains. another is the Argentine entrepreneur whose entire economy is in the US but who lives and pays taxes in Argentina.

I'd pick one of these sub-niches and dig in until I understood their biggest pain. what's the thing they absolutely have to do (by law, for example) but can't. I'd do hundreds of interviews and pay attention to what comes up repeatedly. is there something everyone already solves somehow today, but where no good solution exists? for example: 5 different people mention they solve X in 5 different ways (with a spreadsheet, with an outsourced person, with an app). I'd look for problems where these people have already cobbled together a solution, but where that solution is insufficient. I'd avoid the "wishes" and bullshit people throw into the air, where if you ask "okay, and how do you solve it today?", the answer is that they don't do anything. that's not a pain. be careful with those.

if I find one thing everyone has in common by my 6th call, I'd listen, and then I'd offer that solution to the person. I'd say the pricing is X (even without having the product yet). I'd see if they're willing to pay. the only form of validation is money in the bank. there's no such thing as "really interesting, let me know when you have it; really cool, ping me later." if it's interesting, if it's a pain, you pay for a solution.

if that happens, I'd build a small, beautiful product that only solves this problem and solves it really well.

app that lets entrepreneurs see their conversion funnel and optimize it

I'm not going to explore this idea because I built a company out of it (this was Palabra). even though today I'd probably know how to validate it, the exercise of thinking it through again bores me.

a youtube for action cameras

I was living in thailand when I wrote this list. honestly, I think it's a terrible idea.

tool that let react native developers work on iOS and Android at the same time

there's a huge technical challenge here that, if cracked, unlocks a massive business. unfortunately I think in this case, before thinking about distribution, you have to think about what a solution would even look like. you have to explore the technology.

you also have to question the statement and go back to the problem. I think the problem is that RN apps look very different on the two devices. maybe that's the part that can be solved, and that solves the underlying problem.

email marketing tool for early stage startups

palabra was also this. in fact, this was the idea that started it all! good solutions exist for this today. again, exploring things I already thought about for years bores me.

I've written before about the importance of velocity, and I think in tech we sometimes ask product teams to be fast in a vacuum. we treat velocity as a matter of discipline or willpower, but the truth is that a team's speed is often the result of technical decisions made in the past, and reversing those takes time.

in this post I want to walk through what we lived through at atlas, going from almost no releases to multiple releases a week (4 to 5 a week for the past 6 weeks). I want to share my diagnosis of why fast releases weren't possible when I started working with this team, why they are now, and what we did to get here.

everything I'm about to describe was a learning curve for me. I'd never been through a process like this and I didn't have a plan when I started. I had a clear sense of where I wanted to go and I navigated by intuition along the way.

I want to write this down so I don't forget it, and because it might be useful to others. for that reason this post is going to be long and I'm not trying to make it entertaining. it's meant to be a catalog of everything we did and everything I now know you'd have to do to get here.

why our release process used to be slow

it took me a while to figure out why our product team had so much trouble shipping to production. I could see the symptoms of a team in trouble (low interaction, lots of bugs, reactive problem-solving, no roadmap, projects in progress with painfully low priority) but I didn't understand the causes.

here are some of the reasons I now see for why releases were slow:

- a codebase loaded with tech debt. our team had been through a lot of changes in product and business direction. that, combined with the wrong kind of velocity (shortcuts everywhere, 900-line functions), no tests at all, and no typescript, made the codebase genuinely unmaintainable.

- a non-scalable data model. months of direction changes and very little strategy left us with a data model as bad as the codebase. the data we were storing wasn't reliable, and there were basic cases for our business that the model couldn't represent (everything was a patch; lots of duplicated, inconsistent info).

- a deeply demotivated team. the two points above explain how the team was feeling at this point. any feature we wanted to ship was traumatic, 80% of the day was spent fixing bugs (and there was no clear process for that either), there was barely any communication (literally very few messages on slack), and a lot of disconnect from the rest of the company and the business teams.

- no strategy. this is by far my biggest takeaway from the whole thing and I'll come back to it. in short, there was no clear product strategy, short-term or medium-term. that wasn't the product team's fault. I now know that to build a strategy, there has to be a north star coming from the business side. the symptoms that we were missing strategy were that the rest of the team kept asking us for a roadmap that didn't exist, or that we kept asking ourselves whether we needed a head of product. what we actually needed was a clear objective and clear strategies for the product.

the first few months

the four points above were as frustrating for me as they were for the team. I wanted to think about new features but I could see there was a lot of behind-the-scenes work to do first. these are some of the things we did in the first few months to improve our release velocity:

1. the team needed a win. the first thing we did was a project from scratch: a new app for suppliers. the goal was clear: our product designer had spent months designing screens nobody was building. the frontend team was burnt out from patching an app that couldn't take any more. we needed a blank canvas. a new app, a new component library, a project we could be proud of. we also needed to give backend room for the big changes ahead. we started here and a couple of weeks later we had an app fully designed and 100% built on the front end. it was an early proof of how fast this team could move with better tools. this project never got a backend integration and never shipped, but we hit the goal: a better-designed, better-UX app built 100% by this team.

meanwhile, the backend team needed something to change so we could take on more ambitious work.

2. we needed to redo our data model. the problems were obvious. my hard signal was that the data we were storing was wrong and often contradictory (i.e. two queries that should have returned the same result returned different ones). there was also a softer one: when I looked at the db tables, my sense was that every dev had added columns for whatever they were building without thinking about the whole (the result was a lot of duplicated, inconsistent data). changing the data model is a huge project, and we got plenty of things wrong here. the first is that we couldn't trim scope. we had to design a better model, implement it, migrate the old data, and deploy it. all 4 were extremely hard, and the project took 6 months (we'd planned 1). the payoff was huge once it landed: the data now reflects how we think about the business. our data model genuinely supports the data it has to store, no hotfixes, no patches, no new columns every time we don't know where to put something. (I also have learnings from the decisions we made: we optimized for clarity at write time but didn't think enough about reads.)

3. we needed more and better talent. this is the most sensitive part of this post but I want to be transparent. our team had some fantastic people and some who weren't. for me, parachuted into this team, the challenge was figuring out who was on which side. I tend to think problems with people usually fall into one of two buckets: context (this person is brilliant but the conditions they're in won't let them shine) or individual (this person doesn't work well because of a lack of seniority or agency). this team had a lot of "context" problems, so to see how people actually worked, I gave almost everyone a from-scratch project where they could think and propose as if nothing else existed. some shone, others struggled.

the happy part of this process for me was learning how to hire. with the team in place, we got to work on the next milestone.

4. we had to rewrite the backend from scratch. this wasn't an obvious or easy decision. our backend was what I described earlier: a rat's nest. enormous functions (900 lines or more for very simple things), patches everywhere to handle specific cases, 0% test coverage, no typescript, no real way to test or qa anything. deciding to rewrite came down to asking ourselves which would take longer: a new team spending time to understand everything that was already there, or rewriting from scratch. we went with the second one by pure luck and it turned out to be the right call. today our backend has 100% test coverage, several months after going live, and the architecture is scalable (there are always issues and things to improve, but we're standing in a very different place). we did it gradually, and it ended up taking clearly less time than adding tests and rewriting the old code would have.

5. a clear process for reporting and fixing bugs. all of this had to happen while we kept operating day to day, which meant we were going to keep having bugs. I remember at the time our entire non-technical team was very frustrated with the product team. they were frustrated because things were broken and the team was barely responsive. we did two things here. the first was literally pulling every dev request out of slack, ranking them by priority, and properly fixing the top 5 most frequent ones. that mattered because if devs kept spending 90% of their time on bugs, they'd never get to bigger projects. the second was putting devs on a weekly on-call rotation. the goal was to have a clear owner when a request came in. that gave us some order, but this point is still painful today and I haven't yet figured out the ideal balance between feature work and bug work.

6. the team needed clear expectations and a career path. beyond the motivation that comes from working on projects you're proud of, the other thing that matters to me is that teams have a clear north star. it felt important for this team to know what was expected of them, both technically and on the business side: top-tier devs technically, and deeply involved in business decisions. setting the rules of the game mattered for two reasons: it gave us a framework for spotting who wasn't a fit, and it let us set clear rules for rewarding the ones who were (in our case: monthly performance reviews and a chance to move up the ladder every 6 months).

with all of this in motion and starting to bear fruit, I had the biggest realization of my year. we needed a PM (or PMs), even though I didn't know it yet.

why we started hiring PMs

the idea that the team needed a PM came from an unexpected place. once a few months had passed and the team was running much more smoothly, we suddenly had room to think about features. and we'd been going a long time without releases (because we'd been doing so much under-the-hood work to get things in shape). the need for a PM came out of needing to think about what we actually wanted to do with the product, i.e. what the product strategy was.

quick context on where I'm coming from: I coded for 10 years and never once had a good experience with a PM. on the teams I was on, the PM was someone who handed down a list of tasks with no context and pushed you to finish them by a date. I resisted having PMs at Atlas for years, and I think that was because I didn't understand the role.

the other thing I noticed is that when there are no PMs, someone else does that work anyway. in our case it was the devs: planning, estimating, etc. that's not bad, but it's not the best use of their time. and even if they can plan and estimate, they don't own or develop the strategy, so a piece is still missing.

I got convinced we needed a PM by listening to Lenny's podcast and by starting to ask myself a question: where do I want the product to go, and how do I get us there? as I dug in I learned that a good PM ties both of those together and takes care of the most important thing: strategy.

how we started thinking about strategy

thinking about strategy has been one of the more rewarding things this year has given me. I'll define product strategy the way I think it's most commonly understood: a strategy is a series of consecutive steps that, if executed, get you to a goal.

the best example for me is Tesla's:

Goal: Tesla's mission is to accelerate the world's transition to sustainable energy

Strategy: Build a high-priced sports car → Use that revenue to build an affordable car → Use that revenue to build an even more affordable car → While doing so, also provide zero-emission electric power

the real shift in how we thought about product at Atlas was when we stopped doing things just because, and started ordering our features and ideas behind a big goal.

out of this, we started writing documents (i.e. PRDs) with 4 sections: project mission, vision, strategy, and features. the important part for me is that the four are consecutive. vision flows from mission, strategy from vision, and features are the natural result of executing the strategy.

I could write a whole post about this, but the important takeaway is that we organized what to do on the product side behind a clear objective, and that gave us more order and more meaning.

how we got weekly releases back

after many months, the team started running more smoothly. everything I described above helped us recover release velocity, and although we have new challenges now and the calm is always fragile (because businesses grow and nothing stays still), today we have foundations to build on and we got our release pace back. the team ships 4 to 5 new (meaningful) features to production every week.

I don't think there's a silver bullet when it comes to working with people. these processes are messy, and what worked today probably can't be replicated tomorrow. what matters to me here is to share how we untangled a process that felt very chaotic, with the caveat that it took many months and we made plenty of mistakes along the way.

I hope it's useful if you're going through something similar, and remember there's always light at the end of the tunnel :)

if i had to look for ideas for a new startup today i'd start in two places: problems i experienced firsthand during atlas, and problems that have interested me for years and that i've been tracking. i've been spending time on startup ideas for a few months now. i enjoy the mental exercise of thinking through every angle of an idea as if i were going to execute it. i did it thinking about how i'd build a crm to compete with hubspot here and how i'd build a new email client here.

thinking about startup ideas as an intellectual exercise is fun because it lets me understand which would be "good" ideas. in this post i'd like to share the framework i use to find ideas and to figure out whether they'd work.

how to look for ideas

as i said, my approach today starts in two places: problems i experienced firsthand during atlas, and problems that have interested me for years and that i follow. i'll start with the first.

people don't talk enough about how having a startup of some kind, no matter what, is a great springboard for thinking up ideas for the next ones. while building atlas 2 years ago i worked in every role: i was designer and dev, sales team, head of marketing. when you work on a startup's problems firsthand a lot of things occur to you that could be better: products that aren't enough or are too generic, apps that are the standard for solving a problem but are a pain to use. my takeaway here, and it's something i didn't know before, is that it's very hard to come up with startup ideas in the abstract and without hands-on experience. i imagine a corporate job might replace this experience too, but since i never had one i couldn't say. i also assume you don't need to found a startup. working at a very early-stage one where they give you a lot of autonomy might be enough.

there are some conditions for this to work: just having a job at a startup isn't enough. it's important that the culture is one of ownership, so they let you experiment with tools and solutions, and also (and fundamentally) so problems don't come pre-digested with a solution already attached. it has to be a place where you're the one looking for solutions.

if landing a job at a startup is hard, there's always the option of starting one. that may sound difficult but there are many ways to begin. my recommendation would probably be to go to an incubator, take a bit of capital, and use it to experiment. but having a startup isn't enough either: your style of working can't be hands-off, otherwise someone else ends up facing the problems we're talking about.

(i say it's hard to think about startup ideas in the abstract because i'm thinking about b2b startups. for a b2c startup it wouldn't be necessary and i could use my own experience to think up solutions.)

the second way of finding startup ideas i've discovered is by tracking problems that interest me. some examples: international bank accounts for latam residents. another: stripe for latam. both have had several solutions over the past years. over time i've watched the rise and fall of many of them.

since these are problems i care about, i spend time thinking about what a good solution would look like. and since it's not something i'm working on, i can watch other people's solutions from a distance. this could give me a kind of second-mover advantage if i ever decided to build in one of these spaces. the upside is that i've spent a long time watching different approaches and what's gone wrong. until a clear winner emerges, it's still worth getting into.

technically anyone can do what i've been doing: talk to founders working in spaces that interest me, understand why they chose the approach they chose, really think about what i'd do differently. all of this on top of having the problem firsthand. these two problems matter to me because i live them both. i have opinions about how i'd want the solutions to look. i know what's been tried, and what has and hasn't worked.

there's something important that follows from this: when i talk about finding ideas, i'm not talking about product ideas, i'm talking about problems. we're hunting for problems, not products. they can be problems companies have or problems individuals have, but we're not coming up with app ideas or their solutions. following the examples above, by problems i mean:

1) 'i want to build a startup for latam but every country has different payment rails and integrating them all takes forever' (there's an underlying idea here too: to build a startup for latam you have to build it for all of latam, you can't do it for just one country, and that's where the complexity of managing payments comes from).

2) 'my country's banking system isn't trustworthy and i want to save my money in a reliable account in hard currency. i also want to be able to withdraw that money to my country.'

one way to know whether the exercise is working is being able to formulate the problem in this way. note that the solution doesn't matter. the solution to the first problem can be Yuno (an integrator of payment platforms across every latam country) or it can be Pomelo (a card issuer in 5 latam countries). both attack the same problem from different angles. (one more detail: look at who founded each one. Yuno: ex-Rappi. very likely experienced the problem they solve today firsthand. Pomelo: ex-Naranja-X. they almost certainly felt the pain of issuing cards firsthand.)

how to evaluate startup ideas

TBD

yesterday I read that superhuman is going to launch a new feature that makes the inbox collaborative. email clients are something I've been thinking about and have liked since Palabra, and probably from before. for a while now I've been asking myself: what comes next for email as we know it?

problems email clients have today

I'd like to start by defining the problems email clients (and email as we know it) have today.

- 90% of email is junk. almost everything I get is subscriptions or cold emails. only a small share is actually directed at me, matters, and needs a reply. I guess we could split email into two buckets: sales and not sales. another way to slice it: for-reply and not-for-reply.

- the email that does matter is hard to find. when I do have an email I need to reply to, it gets lost in a sea of other things that don't matter.

- a lot of the format is outdated. there's something strange and anachronistic about writing a message like it's a letter, sending it, waiting for a reply, with no basic metrics out of the box like open and click rate.

- search doesn't work. if I want to find something I received at some point, I usually can't. AI could help here, but none of the email clients I use today do a good job with it.

I think a basic email solution should fix these points: classify emails well out of the box (separating for-reply from not-for-reply), let me search messages quickly and intelligently, and update the format so it feels more like a chat.

what's next for email

watching a demo of what a collaborative inbox could look like got me thinking about two things: 1) how I'd win if I wanted to build an email client, and 2) do all groups of users use email clients the same way? (it feels to me like sales, mkt, cx, and personal use all use an email client in completely different ways.) how would I build an email client just for one of those groups? what would the ideal email client for sales look like?

building an email client for sales teams

some features I think this group needs:

- a shared inbox across the whole team.

- integrations with hubspot and salesforce.

- integration with multiple email accounts (so you can do outbound properly).

- integration with linkedin and sales navigator.

- click and open rate out of the box.

- tracking on whether the other side opened an attachment I sent.

- integration with calling software.

- integration with calendly or similar so you can book calls.

- a calendar view that's easier to see (like superhuman, but done well).

- followup automation. being able to automate a sequence of emails toward a target goal.

for the last few months I've been thinking about how one of the things that keeps me from making the best possible decisions at atlas is my own biases. I'm not just talking about hiring bias. I think about decisions of every kind: what I choose to prioritize and what I don't; who I think has a valid point in an argument; what I consider a good outcome from an experiment; what pace feels right and what's too slow or too fast.

what worries me about my decisions on these things is that the decisions that got us here aren't the same ones that will get us to the next step (and even that idea is a preconception). because I think my way of making decisions has to evolve in order to grow with atlas, I keep thinking about the decisions I make and why I make them. specifically, I think about what a series A or series B founder would decide, someone who has already seen most of the things I'm seeing for the first time. is there another possibility I'm not seeing? are there better questions I'm not thinking to ask?

I wonder what tools exist for fighting bias. beyond questioning my decisions and why I make them, is there anything else?

I'm building a startup. building a startup is a function of time vs. result. a few weeks ago I thought, "what will it be like to live without this pressure to produce results just to keep existing?" "how did I live before, or how did my brain work before living like this?"

a startup is a function of time vs. result. that's the case because by definition a startup is running out of money. in the months I managed to buy by raising capital (could be 12, 18, 24) I only have a finite number of opportunities. of weeks, of sprints, of releases I can ship, of accounts I can close. how do I want to pick them? which features do I want to focus on? which will produce the biggest result inside the time frame I have?

the scarcity of time pushes me to make decisions in terms of outcomes. there's something suffocating about that, and also something freeing. scarcity gives me a frame to make decisions in. since time isn't unlimited, I can't try every path or every idea. maybe I can only try 3 or 4. which ones do I pick?

on the other hand, thinking about everything purely through scarcity is misleading. a startup is supposed to be something huge. startup = growth, says Paul Graham. it's important to remember that whatever we do has to put us at multiples of where we are today.

the problem with thinking purely in terms of outcomes is that it cuts off exploration. could it be that being a good leader is understanding how to balance results and exploration? exploration matters because it's what lets us grow to multiples of where we are now. but it's important to combine that exploration with very short iteration cycles.

writing this I think of General Magic (a film about the device that was the iphone's predecessor). when I watched it, it was obvious to me that those people were more interested in making art than making a product (one of the interviewees says they spent months designing the animations for the icons the device would have). it's hard to think of the iphone without General Magic, but striking that balance seems to be the hard part. exploring and shipping product at the same time. the scarcity of time is a very good tool for that.

things I've read lately about the use of time:

- 100 blocks a day: https://waitbutwhy.com/2016/10/100-blocks-day.html

- Reality has a surprising amount of detail: http://johnsalvatier.org/blog/2017/reality-has-a-surprising-amount-of-detail

- Focus: https://boz.com/articles/focus

- How to get rich (terrible name but a great post): https://nav.al/rich/

- Speed matters: http://jsomers.net/blog/speed-matters