Building meaningful software in the age of AI
When you can type "make me a clone of [any software]" and get working code, why keep building? Quality, intent, and being human still matters. Read: "Everything Starts Out Looking Like a Toy" #142
Read Time: 10 minutes
A HUGE thank you to our newsletter sponsor Pocus for your support.
If you're reading this but haven't subscribed, join our community of curious GTM and product leaders. If you’d like to sponsor the newsletter, reply to this email.
Brought to you by Pocus, a Revenue Data Platform built for go-to-market teams to analyze, visualize, and action data about their prospects and customers without needing engineers. Pocus helps companies like Miro, Webflow, Loom, and Superhuman save 10+ hours/week digging through data to surface millions in new revenue opportunities.
“Everything Starts Out Looking Like a Toy” is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.
Hi, I’m Greg 👋! I write essays on product development, including system “handshakes”, the expectations for workflow, and the jobs we expect data to do. This started with What is Data Operations? It grew into Data & Ops, a fractional product team to create amazing UX and product experiences.
This week’s toy: a site that helps you to remember to stretch. This is an excellent example of just-in-time next actions, and I’m thinking of making a shortcut reminder on my phone to deliver this prompt to me daily. The best personal trainer might be past you making decisions for future you, precisely so you don’t have to make those decisions in the moment. Edition 142 of this newsletter is here - it’s April 24, 2023.
The Big Idea
A short long-form essay about data things
⚙️ Building meaningful software in the age of AI
Today I asked ChatGPT to help me build a Next.js app with a Google Authentication to help me gate access to information using a Google Domain. I also asked it to build a search form to send questions to the OpenAI API and to return the results in a web page. Although I’ve built web sites before, I didn’t know how to do this before I started the session. And I got most of the way to a functioning application within about 30 minutes.
In the age of AI, building a solution – even when considering a sophisticated stack of software – is only a few prompts away. We can quibble over whether this was good or bad code, whether it truly can replace a developer, or whether this app is fundamentally the average of all of the code it finds.
The point of all of this discussion is that lack of knowledge of a technology is no longer a barrier to build applications. Building meaningful applications that people want to use will still be a barrier, and will be a powerful differentiator for standing out among the application clones and half-built apps that are coming.
What makes truly good software?
A good plan and an understanding of the problem are necessary to build good software. To improve that and create a really powerful result, you need to go beyond the tools and the stack you are using and get to the motivation behind a feature.
Why do people want to use software? To solve a need. To finish a job. To improve a capability they had before. To invent a new one. So they ask for features and ideas that they think will achieve that goal. If there was a software genie that granted wishes, this would work great.
The resources to build this software are limited. The requests can be divergent. It’s not always clear to know what to build, and sometimes not clear how to build it. So when you think about any kind of software – whether driven by an automated AI agent or by a person – you need to start with principles in mind that will force you to make decisions and limit the items you build to the ones that match those principles.
If you think about what AI tools do well, they pattern match incredibly well. And they pattern match using context. Your personal context and the company’s context are your most powerful source of intuition for knowing what to build.
Here are a few examples of drivers that help drive decisions like these:
Short term vs. long term
Are you building to plug a hole, fix a bug, or “do that thing the customer asked for”? These might be short term fixes that could be aligned with other goals and might be distractions. Short term fixes need to be balanced against longer term goals, and the tension arises when customers get upset or feel that expectations have been mismatched. Long term goals are valuable, but not if you never make progress.
Maximize vs. satisfy
When you design a solution, to what degree are you solving? Maximizers try to think of every nook and cranny, every possible solution, and the best possible idea. (They might get stuck at a local maximum, too.) Satisfiers build the necessary piece of a solution to resolve the issue. They run the risk sometimes of overlooking an edge case or an important problem.
Strategic vs. Committed
Here’s another version of the short term/long term problem. Strategic features provide a competitive advantage or help you build a strategic “moat” that’s hard for other companies to breach. A strategic feature aligns with the overall company objectives and pushes you toward the long-term vision. In contrast, a committed feature is based on a commitment you made to a customer. They believe you will build it in a certain period of time, and it may or may not be aligned with your strategic goals.
Technical risk vs. execution risk
Some of the things you’d like to build don’t have a clear technical solution and need to be researched. And some of these might need invention to solve and it’s not clear if it’s even possible. There are other problems that are known problems and are solvable if you apply resources for a known period of time. But you need to stay focused, avoid resource conflict, and generally get stuff done to achieve them.
There are not enough resources to solve every problem
Richard Mironov calls the balancing act of knowing what things we are going to build “the chocolate cake problem.” We can all look at the cake – a desirable object representing our capacity – and it’s hard to know exactly when it’s going to be gone. If you have teenagers, as in Mironov’s example, the cake might be gone very fast. Going with analogy, the different kinds of drivers in our world and the size of those initiatives defines how fast the capacity will be gone.
How will you make those figurative calories count?
My take on this is that the AI builders are a lot like teenagers in the cake story. They can do anything you want and they have seemingly boundless energy and speed. They also make resources disappear like locusts, and you need to establish some boundaries on them to make sure they don’t have unintended consequences. Ultimately, the software you build needs to create, communicate, and deliver unique value.
That is the same goal whether you build software with AI or by typing each line by line and doing it in the most basic text editor.
To build truly
good great software, balance what you and your team want to build with how it will be perceived and used.
Why not build a product brief of first principles thinking? The worst thing that can happen here is that you will get a lot clearer about what you are building and why.
Note: this applies for new features on existing products too. If you don’t know why you’re building something, why the customer will use it, and how they know it is working … think harder.
Here are some exploratory questions for your product brief:
Who are you building for?
How do they perceive value?
What do you need to do to get them to try it?
This might sound reductive, as it focuses on psychological needs and less on feature delivery. But software is a human problem. (Even server-to-server software.)
AI software builders pattern-match to find the next likely solution to a token in their context based on the model they have built. This means they have a mathematical likelihood to end up in the same place as a human-centered software builder, and they won’t know why.
Building your why is the essence of great software. At the core of that is delivering value to your customers.
What are the components of value?
You’ve probably seen Maslow’s “Hierarchy of Needs” pyramid. If you break this down into the items that motivate software buyers, you’ll get a list of items they consider when they are thinking about using an existing or new tool.
We often focus on functional benefits when building. What capabilities can we add that people didn’t have before? What existing things can we improve?
Sellers often think about how cool their product is, and how much buyers will appreciate the added utility their service brings. However, they overweight the benefit they are offering by about 3x. Buyers also have a similar disconnect. They are thinking about what they will need to make a switch, often in an emotional way, and this causes them to need a 3x benefit to get to a point where they are willing to switch.
The combination of these eager sellers and not so eager buyers requires a 9x+ effect to convince both of them to come to the table. You may recognize this as a 10x factor, or a point where things really become obvious when there is a benefit.
AI can pattern match to past successes. It will have a hard time reaching the goal of a human response to a problem. As Lara Hogan has coined, it’s a thermometer, not a thermostat. It might eventually get there … but not yet.
The future of software, and of work
The future is coming faster than we think. And the average person doesn’t get yet how it will change their work and life. Pew asked a panel for their attitudes on change over the next 20 years - one wonders what the actual impact on these same respondents will be over the next 36-60 months.
If we use the challenge that AI poses for software makers as a template for the challenges regular people will have with rapid technological change, the basic principles apply:
Focus on the value delivery.
Don’t discount emotions - they are one of the key drivers for software adoption.
Ruthlessly prune ideas until you have one that could be dramatically better.
Don’t wait until you have a dramatically better idea to start and iterate.
What’s the takeaway? Building software is a human problem. When you add AI to that problem, the best way to do that is to shortcut some of the mindless tasks you would otherwise do manually and to create options to iterate. The final value creation is going to be judged by people, so use your people skills to be more compelling than a bot.
Links for Reading and Sharing
These are links that caught my 👀
1/ Using AI tools to create a dog portrait - This is a pretty interesting story of how Jake Dahn created a portrait of his dog using a software model trained on his dog pictures along with other software to create this end result.
Whether or not you like the idea of using AI tools to create photographs, you’re probably already using them without knowing about it. For example, if you take pictures with an iPhone, the end result is being adjusted. Jake’s article is a good compilation of the artistic choices necessary to go from original idea to curated, original result. (Yes, I know that calling Stable Diffusion art “original” is problematic, and I do think this is a moderately original result based on Jeff tuning his own model).
2/ What is BigO Notation? - Erghest Xheblati describes the process of querying data to clarify the types of questions that might take a lot longer than you might think. If you had asked me to explain what makes some queries consistent in speed, some take a linear amount of time based on the data involved, and some take … a lot of time I would not have been able to explain things as easily as Erghest.
3/ All things PLG pricing - Kyle Poyar’s PLG Pricing 201 explains – in plain english – many of the things marketers and product folks are doing in correctly with PLG pricing. My favorites here involved tweaking the offering to allow you to change the game later. If you treat the current pricing offering like a product, it will seem clearer how to adapt it, expand it, or sunset it according to market needs.
What to do next
Hit reply if you’ve got links to share, data stories, or want to say hello.
Want more essays? Read on Data Operations or other writings at gregmeyer.com.
Want to book a discovery call to talk about how we can work together?
The next big thing always starts out being dismissed as a “toy.” - Chris Dixon