It worked!
A decade later, I still keep the habit of writing an article every month. Over 120 sessions I’ve slowly gotten better at writing, learned tons, and built up an archive of some of those lessons. These articles have now been read millions of times, and fed many great conversations and friendships.
Simon Willison recently wrote about the formidable power of streaks:
The best way to get really good at anything is to do that thing on a regular basis, thoughtfully, and with the goal of doing it slightly better every time.
This is true, in my experience. I would say, further: the best way to start actually doing something is to try doing it once a month.
While monthly is not frequent enough for most work habits, it can be unreasonably effective when the activity is atelic – that is, for its own sake. Something you enjoy and find worthwhile, but don’t yet do regularly.
A really nice thing about a monthly habit is that, even if you’re busy – perhaps you’re a parent, a founder, an over-scheduler, or all three – you can still make time for once a month. There are, on average, over 30 nights in a month to pick from! And 30 days, to boot. 8-10 of which are weekend days. The month is your oyster.
Here are some examples I’ve found of potentially worthwhile monthly habits:
You don’t need to keep ten monthly habits at once, of course. Although you easily could!
The point here is simply that if there’s something you enjoy doing, and you wish you did more often, try scheduling it once a month.
The second Sunday of every month could be Long Bike Ride Day. The last Thursday of every month could be Product Drinks. The last day of every month could be Just Publish Something Day. Just try it for a few months!
It might just stick.
]]>While GPTs may prove useful in their current form, they’re part of a grander plan. The exact path is yet to be seen, but I believe OpenAI tipped their hand with a very specific choice in how GPTs are designed.
Here is a common model for building a custom chatbot on the GPT-4 APIs:
OpenAI GPTs do not support this model.
Specifically, unlike many API-powered bots, GPTs are not allowed to do Step 2: they cannot have the first word. A GPT author can provide a blurb describing the GPT, or provide suggested inputs to the user, but GPTs sit silently until you send them some kind of initial message. GPTs force a flow like this:
This was initially baffling to me as a developer. When we built the Feedback Wizard, a LLM-backed structured coaching experiment, it was clear that the Wizard should start the conversation by asking the user the first question. This is how a lot of software works: you start it up, and it asks you something.
This “computer starts with a question” model seems especially well-suited for building chatbots. For example, the whole point of the Feedback Wizard is to ask you questions. Attempting to build a GPT version of it under the constraint that the GPT can’t start the conversation was annoying.
Meanwhile, GPTs are set up to offer “conversation starters” – snippets of text users can tap to get things rolling, which force developers to think about how the GPT might be queried. When putting together the Feedback Wizard GPT, I felt pushed into writing conversation starters like “Can you help me frame some feedback for a co-worker?” – entry-points that felt redundant, given that the user has already selected a feedback coaching tool. However, while doing this, it struck me why OpenAI designed GPTs to be written in this backward-feeling way:
GPTs have to wait for user input before saying anything, because that will make them useable as building blocks of an Everything Engine.
ChatGPT is powerful, but has many limitations. No company can build, by itself, an Everything Engine: one text box that you can type into for any problem. OpenAI experimented with plugins to expand ChatGPT’s capabilities, but plugins competed with one another in-context, and the business model was questionable. Worse, there was too much friction to finding and selecting the plugin you wanted to use.
While GPTs may seem like they have similar problems, they offer a clear evolutionary path to a low friction, scaleable, and potentially highly profitable user experience. In a world where many useful GPTs exist, and those GPTs are written to respond to user input rather than start conversations with people who select them, ChatGPT can incrementally become an Everything Engine simply by routing requests to the best GPT for the job.
Let’s say you ask ChatGPT, “Can you help me with this math problem?” it could offer to send your query to the Khan Academy GPT, built by learning experts. If you ask, “How are the markets today?” it could sub into Yahoo Finance’s stock market GPT, equipped with realtime market APIs. If you ask an Everything Engine “Where should I go on vacation?” it might leverage a travel expert’s lovingly crafted GPT for helping you consider your options.
Just joking, it’ll offer the Tripadvisor GPT. Or whoever the highest bidder was. We won’t see sponsored GPT results for a while, but an Everything Engine would be the most compelling ad opportunity since web search results pages. If it works, the incentive for OpenAI to accept payment for GPT promotion will be immense.
LLMs aren’t great at math, but Wolfram is.
Admittedly, OpenAI might retain enough of their not-for-profit DNA to resist the urge to monetize the Everything Engine like this. Or maybe Sam Altman will be fired again on the path to building it. But even if they don’t do it, Google will.
If I’m right – if a model and ecosystem like GPTs can be used to build a compelling Everything Engine – then an ad-supported Everything Engine is coming. I’m more than willing to pay $20/mo for ChatGPT Plus, but most people won’t. But they will visit a free website where they can type into a text field, and it will answer their questions with ads.
Right now, that website is Google for most people. But no matter how much work Google puts into their Quick Answers and Bard, no one company is going to be able answer everything on its own. Serving the long tail of queries in one place – creating an Everything Engine – will require an ecosystem of developers and content providers.
In the coming years, if we do start to see the emergence of the Everything Engine, well… we will live in interesting times.
Thanks to Adam Lisagor, Jenn Cooper, Chris Parrish, and Paul Kafasis for feedback on this article and the ideas behind it.
]]>In 2010, my co-founder Nigel and I started Steamclock. The vision was to build products for clients, and use those profits to fund our own product development. Which worked! Mostly. We’ve built a client business that’s been growing and profitable for a decade straight, which has funded a lot of our own product exploration.
As we grew, though, a flaw in our plan became clear: trying to build your own products within a client services company puts both businesses at a disadvantage. Specifically, a focus disadvantage.
There are fundamental differences between building a product for a client and building a product startup. They justify different mentalities, approaches, and habits. When you have other revenue coming in, you can get away with hobby products – such as building a polished, well-loved app that gets a million downloads, yet loses money. For example.
These exploits may feel partially successful because they’re fun and educational and popular, but they distract from doing what’s best for the product or services business. While hobbies can be rewarding and informative, by definition they can’t support a talented team, iterating and improving towards something truly great.
Me personally, I like to build with a talented team, iterating and improving towards something great. That’s how we do our client work, and that’s what I want to do for product. But trying to do both in a combined team makes it hard to do either well.
So, last year, we started the process of splitting our client services and product development work into separate businesses.
From one perspective, it’s a simple change: despite our many product experiments, Steamclock is fundamentally a client services business. Given that, this change is less about splitting out a product business, and more about founding a new one.
From another perspective, it’s a complex change: I’ve been focused on our client services business for over a decade. Despite a lot of progress in giving our teams ownership and independence, I’ve still been a bottleneck for some key processes like hiring, marketing, and strategic planning. To focus in on product I knew I needed to push to the next level of delegation and handoff – but after 12 years I found myself a bit burnt out.
After some angst and coaching, I devised a plan:
You know – an experiment. While I knew it was needed, I expected this process to be unpleasant and difficult. I was worried I’d come back to a bunch of firefighting and un-delegating.
I was happily wrong.
As a leader, you do two kinds of work:
A big benefit to teams with a habit of transparency is that there isn’t a lot of hidden work. I’d been doing a few invisible tasks – “when we do strategic planning, this is how I prep it,” or “every quarter I run this analysis on the P&L” – but for 80% of my job, the parts of my work that needed delegation were familiar and legible to the team.
Once we had a map for me being away, a key question remained: how often should I check in? We considered a weekly or monthly checkin or review, but that would diminish the value of the experiment. Instead, we devised a very short list of emergencies I might be pulled in for – e.g. a surprise cashflow problem or the departure of a key leader. Then, we worked to set the team up with the context, docs, and explicit authority to handle everything else.
While I expected this prep work to be a grind, it was actually… fun? We have an excellent team, and the time-boxed nature of the mission felt very purposeful. I iteratively handed off my tasks, spent less and less time working in the business and more time writing docs and coaching (which I enjoy), and after 3 months of prep the team was ready to rock.
Since I am me, I knew that – without some structure – my sabbatical would quickly devolve into Allen unofficially working. I also knew that, after 12 years of full-time work, I had more side-projects I wanted to do than could conceivably be done in 3 months. I know going on a 3-month break is a huge privilege, so I didn’t want to fork it up.
To give myself some guardrails, I chose a theme for each of the 3 months:
I was not great at doing nothing. I did a lot of forest-walk thinking, reading AI papers, and completing projects around the house. While I didn’t do nothing, I successfully stayed out of my work email and Slack – and got no emergency pages from the team. Month 1 was a success.
The “Trying new things” month was glorious. I tried new instruments, technologies, fitness routines, restaurants, books, habits, movies, priorities, games, and mindsets. Not just things I’d been meaning to try, but stuff outside my comfort zone. It was joyous. Since that month, I’ve kept up the new mindset and it’s been wonderful.
I also got a lot out of the preparation month. I started going to new meetups, reading books about products and startups, and getting clear on my mission. I love product work, so I was happy to be digging into exploring and talking to potential customers, before my sabbatical even ended.
While I feared returning to a list of fires, everything pretty much… worked. In my absence, our team delivered good work, kept clients happy, and retained everybody. The preparation paid off. In contrast to the bad old days when I was the only person with enough context to make big decisions and keep things moving, in recent years we’ve developed excellent project management, operations, and Directors of Engineering and Client Services that support and execute for our clients. It’s pretty great.
Of course, there were some gaps in my absence. But having proven out what I was actually needed for – as opposed to what I was doing out of momentum – it’s been a lot easier to work through filling them with further experimentation. It’s a big level-up to go from “I worry that blog posts won’t move forward without me around” to “How do we get blog posts moving again, now that I’m not running them?”
Meanwhile, I’ve gotten my wish: I’ve been focusing more and more on product work. I’ve pursued product research questions like “How could team communication get far better?” and “How do effective leaders manage their time and attention?” Recently, I’ve led prototyping and customer validation on a tool that helps product teams work with LLMs. I’ve been learning more than I have in years, and am excited to ramp further on product work in 2024.
The lesson, at least for me, is that even when a big change seems risky, there’s a path to doing it well. In retrospect, that may seem obvious. Over the years I’d already reinvented my job repeatedly – from founder, to manager, to leader of managers – but this felt like the biggest and most daunting change yet. Still, the ingredients have always been the same: a team, a plan, and some experimentation.
And now, for more of that.
]]>