Hiring a Chief Marketing Officer is one of the hardest tasks technical founders face. Candidates present well, and the role spans such a broad range of skills that it can be difficult to know who to choose. You can easily fall into the trap of hiring a slick, big-company executive who wants to invest in building your brand. They’ll bring in creative agencies, hire a lot of people, spend a ton of money, and the messaging will be so abstract no one knows what you actually do.

The most important thing to recognize when hiring a CMO is that marketing is a broad discipline. Its span includes public relations, analyst relations, demand generation, pipeline analysis, positioning, product marketing, website development, search engine optimization, content marketing, storytelling, sales enablement, case studies, video production, webinars, event marketing, and more. And because it’s 2026, you’re also looking for marketing leaders who are savvy about using the latest AI tools to better generate and execute marketing campaigns.

Anchor On One Thing

No one is good at all these things. So you must pick the one or two areas of focus where you want your marketing leader to have deep expertise. Then you can add other skills through individual hires or external agencies.

If you’re still figuring out positioning and product-market fit, you’ll need someone who really understands your market, target customer, and their pains. If you’re further along and have good repeatability, building pipeline through demand generation is likely the better area to focus on — for most startups, it comes down to anchoring on one of these two functions and executing it well.

When you interview a candidate for this role — or in fact any executive role — you should focus on the challenges you’re facing right now. After all, if you hire them, that’s what they’re going to be working on. It’s nice to know what they’ve done in prior roles, but mostly you care about whether they can help you accelerate growth by unlocking new opportunities.

I recommend throwing at them whatever challenges you’re grappling with, such as:

• How can we increase pipeline coverage?

• How can we better respond to the competition?

• Should we expand into the Enterprise market? If so, how?

• How do we improve our product position to be more compelling?

If the candidate demurs, responding with “I don’t know your business…,” acknowledge the concern and then gently prod them to venture forth with whatever ideas they may have. If they still aren’t comfortable, it’s unlikely they will succeed in your organization. While you can’t expect candidates to be experts in your business during an interview, you need someone who can dig into complex problems, ask questions, diagnose the situation, and formulate an effective strategy. You need creative problem solvers.

You’re not going to get perfect answers in an interview, and not every suggestion will be applicable. But you should at least get two or three good ideas when you interview an executive. If you don’t, don’t expect to get good ideas after they join.

Collaboration Is King

One of the most important elements of a marketing leader is that they need to collaborate closely with other executives, especially the head of sales and head of product. But you can’t just ask “Are you collaborative?” Instead, I recommend asking what they look for in colleagues in adjacent organizations. If there is genuine collaboration, you should hear detailed examples of working together on product roadmaps, lead generation campaigns, customer events, or more. If you get anything less, keep looking.

Many tech companies suffer from an “us versus them” mentality between sales and marketing. If an executive has not operated in a highly collaborative environment, they won’t have the right foundation of trust and respect to build upon. If the leaders at the top can’t or don’t collaborate, that behavior becomes the norm throughout the organization. It leads to poor coordination, weak execution, and a lot of finger-pointing.

Don’t Go Too Far Afield

While many marketing skills are generally applicable (good storytelling, quantitative analysis, competitive analysis…), the specific application of those skills is always context-dependent. So when you’re hiring, it’s best to look for those with experience in your particular market segment.

If your business is selling a technical product to technical buyers, you should probably not stray too far from that area. Ideally the marketing leader is familiar with the particulars of selling to your customers or a similar group. If you’re selling infrastructure to developers and software architects, and a candidate has been in the cybersecurity space, that might be close enough. If you’re selling to line-of-business buyers (legal, finance, medical, marketing, etc.), you’ll want someone who is used to demonstrating ROI and case studies that showcase those areas.

Similarly, if you’re looking to build a great product-led growth engine, look for someone who has been successful doing just that. If you’re looking to conquer the Enterprise market, look for people with five or more years in that field. It’s not to say you can’t cross-pollinate some skills, but you want a fast ramp for people, and there’s no shortcut to deep experience.

What you’re looking for is someone with a track record of success in the next stage of growth your company faces. Be careful not to get too far ahead on the revenue curve. If you’re currently on a path from $10m to $30m, an executive who helped grow a company from $200m to $500m or beyond is unlikely to want to roll up their sleeves and personally manage product launches and campaigns.

Often the best approach is to look for the “up-and-comer” who has learned from a great marketing leader, has depth in one or more areas (ideally demand gen or product marketing), and has seen great execution and leadership up close.

Great Managers with Deep Skills

The best marketing leaders I’ve worked with — Pete Baker, JD Peterson, Mike Ryan, Ruoting Sun, Jeff Wiss — all had deep skills and expertise in their domains. They brought a creative approach to problem solving and were highly collaborative. They were also great managers who helped develop talent in the organization. They didn’t micro-manage or second-guess.

When I first joined Duo Security, Jeff Wiss was one of my first hires as VP of Marketing. Jeff and I had worked together several times previously. Duo was quite small at the time (around $6m in ARR), and Jeff was able to build a results-oriented demand gen machine that scaled for years. He was also great at PR and positioning and was highly respected by the creative team. He had huge impact at Duo and even after he left, he was brought back by Cisco as a consultant to help reinvigorate the brand.

5 Key Principles for CMOs

Jeff believes a great CMO needs to live by five key principles: Velocity; Simplicity; Measurability, Predictability, and Repeatability. At Duo he built a high-performance demand gen system so he could say: “If you give me an incremental million dollars to spend, I can deliver $8 million in pipeline and these are the precise quarters in which that pipeline will appear.”

All these top leaders set a high bar for collaboration, creativity, and results that created a high-performance culture through continuous experimentation. What tied all of them together, though, was consistency: launches that had impact, pipeline that grew, positioning that focused sales, and teams that got stronger under them. That’s the track record you’re hiring for — a repeatable pattern of making the people and numbers around them better.

The best CMOs don’t just build the growth engine — they get behind the wheel and drive it.

Hiring execs is always hard. I’ve also written about hiring your first VP of Sales and the VP of Engineering.

If you’ve ever spent a week in back-to-back meetings and then wondered where the time went, that’s a sign you’re stuck in reactive mode. It’s one of the things I’ve seen founders struggle with most: figuring out their own role once the company gets past the initial crush of building and launching their product. Typically they’ve hired a growing team of executives, and now no longer need to fight every fire, drive every action, or make every decision. So if you’re not supposed to be in reactive mode anymore, what are you supposed to be doing?

This is when founders need to take a step back and look at the longer horizon, beyond the next deal, the next hire, the next sprint. Good leaders move from reactive mode to proactive to guide the company’s growth and strategy. You are looking for opportunities, improving collaboration and unblocking bottlenecks so that the organization can grow.

An important element of managing this transition is to re-assert control over your calendar. If you don’t manage your calendar, it will manage you. There are an infinite number of ways to do this. You can use any system you like, but you must have one.

Over several decades, I have tried various approaches to time management, often based around GTD - Getting Things Done. While my system isn’t perfect, it works for me and perhaps it will inspire the development of your own time management system.

The Four Quadrant System

Every Monday morning, I draw a cross in my notebook to create 4 quadrants. At the top I write the date. In the upper left quadrant, I list all the meetings scheduled for the week. This includes staff meetings, departmental reviews, one-on-one meetings, board meetings, etc. These are commitments that have to happen. Depending on the week, this is usually 6-10 meetings. There are no “optional” meetings. I’m either committed or I’m not attending. I don’t do a lot of “skip-level” meetings, that is , with people who do not report to me directly. And I definitely don’t take such meetings on a recurring basis, since I don’t want to blur formal reporting lines.

I may not love every meeting I’m in, but I enjoying checking them off as they occur. I enjoy checking things off so much, that sometimes when unplanned work occurs, I write it down and check it off immediately. Call me weird, but it works for me.

In the lower left quadrant, I list specific deliverables I need to get done. This might include strategic plans, hiring plans, budgets, product launch plans, pipeline or roadmap reviews, board decks, etc. Depending on what is going on this list might range from 4 to 6 items. Often these are areas of intense focus, creative work, or both. I don’t generally block out my calendar to work on these items, but that’s a legitimate way to operate if other people are adding things to your calendar.

In the upper right quadrant I write the hard things I need to deal with that are not deliverables due this week. Generally this is a short list of 3-5 items. They are weighty items, but usually there are not that many. The list might include preparing an upcoming board deck, a strategic plan, making an offer to hire someone, terminating someone, selecting a banker, deciding to kill a project or any number of complicated decisions. Not every item in this list will get completed in a single week, but I try not let things carry over more than a couple of weeks.

In the lower right quadrant, I write whatever personal items I need to take care of. This is generally a small list of 4-6 items. It will always include exercise (running, cycling, going to the gym), personal obligations (dentist visits, taking my car in for service, booking future travel) and social obligations. For things that are personally important, like running, I always find the time, even if it’s at 7am.

This four quadrant system lets me see the week in advance and ensures I have a fresh view of what’s important every week. It also gives me a sense of control over the week. Before the chaos starts in, I know what needs to happen. This helps me dedicate time to harder, long-term tasks and not let my week get jammed with low-priority items. If we are behind on sales pipeline, I’m going to make sure I spend time on that issue. By writing it down, I ensure it gets attention.

Don’t Kick The Can

I typically review the quadrant throughout the week. I love checking things off, even if it’s just a meeting that occurred. That also forces me to see the high-priority items that are still awaiting action. As the week proceeds, there is usually a sense of progress. The hard stuff is getting worked on.

Usually late on Thursday, or at worst, Friday morning, I look to see what has not yet been completed. Then I make sure as many of the critical items get done as possible. I’m not one to kick the can down the road week to week. I make sure the hard things get done, if only so I can check it off my list and be done with it. Even if it’s a tough decision or difficult action like terminating someone, having written it down, I know it will get done.

Meeting Notes

In advance of any given meeting, I will allocate a separate page for notes. This includes my advance preparation such as defining the agenda if it’s a meeting I’m running. Or even notes to remind me of critical ideas that need to be discussed, hard questions, or just reminding me to listen, be gracious or thankful. I typically write action items on those detail pages, rather than on the weekly quadrant. This includes my own action items or my expectations for others. If there are action items I want to be clear who has them and when they are due.

I hate being a bottleneck to others, so when I review the quadrant late in the week, I also review notes from meetings to make sure my action items are getting done. If necessary, I will follow up with others to make sure there’s no confusion about decisions or action items and nothing got lost.

Build Your Own System

While my system is not foolproof, it works well for me. It brings focus to my week as well as a sense of progress. I see that decisions are made, actions are taken, follow up is clear. It’s exceedingly rare that something falls through the cracks.

This system didn’t come to me fully formed. I learned it from a mentor and former boss, Del Yocam, who had been President and COO of Apple in its early days. Del carried a notebook everywhere and wrote down everything that needed to get done. I’ve tried plenty of software tools over the years, but for me, nothing beats the simple act of writing things down and checking them off.

You don’t need my system. You need your own. But whatever you build, the goal is the same: make sure your attention reflects your priorities, not everyone else’s.

Mentor and Borland CEO Del Yocam and me outside the Kremlin in the late 1990s.
Delphi was widely adopted in Russia thanks to a liberal country-wide site license.

We took thirteen venture-backed founders to a remote island in the Finnish archipelago. It sounds like the setup for the next Knives Out — but what actually happened was much better: four days of workshops, peer learning, hard conversations and rethinking what comes next.

Building a company is lonely work. What makes FourthBox different is that founders realize they’re not alone — every challenge they’re wrestling with, someone else in the room has already faced. Coaches Anna, Clint, Marjorie, Marten and I helped guide those conversations, and our event coordinator Anton kept the whole operation running smoothly. Most founder conferences send you home with a tote bag and a hangover. FourthBox sends you home with conviction and a plan.

More Diverse Attendees, More Stage Consistency

This year’s attendees were quite diverse with 5 women founders and 8 men with a mix of nationalities: American, Chinese, Finnish, French, Irish, Swiss and more.

All of the companies were B2B businesses within a range of roughly $5 million to $30m in revenue. This was a more narrow band than last year and led to a higher degree of coherence. Many founders are going through the same growth challenges. How do I scale our culture? How do I think about our category and competition? How do I make my company more AI native? How do I prioritize my time? When should I delegate? How do I up level my team?

About 75% of the program was determined in advance based on our attendee surveys. Although we deviated from the program when necessary, I personally felt more prepared (and less jet lagged!) this year. For a couple of workshops we split into two groups, which enabled founders to pick the topic most relevant to their current situation and stage.

Coach Anna Binder, who worked as Chief People Officer in several high growth startups, had a major role in shaping the program. She also worked her magic to build an environment of high-trust within the first hour, which set the stage for maximum learning.

More Focus on Sales, Speed Coaching

There were two significant changes in the program based on feedback and observations from last year. First of all, we added a clear sign-up process for one-on-one speed coaching instead of the ad-hoc process we used previously. Founders could schedule time with any coach based on their area of expertise. By having a signup sheet and designated slots, we ensured that people could dive deeper into their particular challenges. We were immediately oversubscribed for coaching sessions.

While it made for a long day for the coaches, it enabled us to go much deeper and provide specific guidance on the exact circumstances founders face. Several attendees told me these were among the most valuable sessions of the bootcamp since it enabled them to develop specific action plans.

The second change was to bring in a coach who was more steeped in building the sales function. While several of the coaches have run sales, we don’t live and breathe that function the way a career sales leader does.

We were fortunate to be able to entice one of the foremost experts in this area by inviting Marjorie Janiewicz, CRO of Mistral. Marjorie has had a decades-long career in sales at startups and has seen the range of motions from product-led growth, SMB, Mid-market and Enterprise sales. She has built teams, hit quota, hired, fired, and is humble enough to share the mistakes lessons learned along the way.

I don’t think our founders had ever seen the kind of passion, leadership and brainpower that Marjorie brings to Sales. The audience was rapt, throwing out a wide range of questions, taking notes and learning from the best. Marjorie’s sessions ran overtime demonstrating just how much appetite there was.

For technical founders, there was a deeper appreciation for a methodical well-thought strategy to scaling sales. Sales is not just a tactical side quest. It is the lifeblood of any successful company. One founder said she had never realized you could bring a scientific approach to sales. It gave her confidence that should could make these ideas work in her very technical organization.

What Makes It Work?

Many of the founders said they had attended other larger founder conferences and put FourthBox in its own category. It’s a small group, by design, and focused as much on peer learning as from the coaches. There are no big stage presentations, slides or lectures. It’s a hands-on approach, working through issues together.

The Finnish archipelago is a unique location, but not easy to get to. We’ve chosen that over Napa, Santa Cruz or other Bay Area locations precisely because it is remote and isolated. We are there for one purpose: help founders with the toughest issues they face.

Being alone on an island eliminates a large number of distractions. There are no board members, investors, co-founders, colleagues, or outsiders which leads to a high degree of openness. Founders are spending time with peers who are going through or have already dealt with many of the same issues.

We had some afternoon and evening activities including kayaking, boating, (very) cold evening plunges in the Baltic Sea and three types of sauna. These activities help create deeper bonds and often end up becoming extended bull sessions.

Most founders coming from the US spent the first part of the week elsewhere in Europe meeting with customers or partners. That helped lessen the travel burden.

We may not always choose Finland for this event, but picking a location with few external distractions helps get founders out of their element and focused. We will investigate other locations to determine where we can find the perfect balance of nature, camaraderie and outdoors.

Four days on a remote island won’t solve everything. But being in the right place with the right people solves more than any of us hoped.

The FourthBox is a not-for-profit and we run on a break-even budget (most of the time.) I’m grateful to our venture sponsors who have made this possible: Benchmark Capital, Index Ventures, Scale Venture Partners and Atomico. I’m also grateful to our coaches and founders who all took the extraordinary leap of faith to participate.

In the ancient days of the software industry (e.g. pre LLM), your technical architecture and talent provided a competitive moat. If you had top-notch engineers building out new technology, you had a one or two year lead against the competition.

Savvy investors would ask: why can’t Google build this product in six months? The reality was that although Google (or Adobe or Salesforce) could build it, they probably wouldn’t. (If they did, it would be a crappy solution that no one liked!) Nonetheless, investors felt compelled to ask, and founders felt compelled to provide some kind of answer, even if it was a stretch.

With AI and vibe coding there’s a mild panic among SaaS investors because now it seems that software isn’t defensible. If your customers, partners and competitors can build your app in less than 10% of the time it took you, then that moat has evaporated.

Were Startups Ever Defensible?

But when I think back to the early days of Duo Security or Zendesk, were these startups really defensible? From a technical point of view, probably not. Same with companies like HubSpot, Box, Twilio, Atlassian, ServiceNow or Workday. Yes, those product lines became more sophisticated and comprehensive over time, but the initial versions? With a good team, you could have matched their features in a few months. Today, with tools like Claude, it’s a matter of weeks.

But despite the bravado that most founders have about the quality of their engineering teams, that’s not what makes a startup defensible.

What really distinguishes great companies is their domain expertise, customer focus and culture. The reason Zendesk could disrupt incumbent Enterprise vendors was because it delivered a beautifully simple solution compared to traditional customer service ticketing systems. Sure, Salesforce had a competing solution. But it was like a 747 instrument panel you had to assemble yourself. When Salesforce acquired Assistly they added to the confusion by having two competing products.

Meanwhile, Zendesk continued to preach the value of simplicity. We had great product, engineering and design teams. What made them great was the focus on keeping things simple.

The other competitive advantage Zendesk had was we were customer focused and moved fast. There was minimal bureaucracy (at least in the early days) so decisions could be made quickly without layers of approval. Every time we went up against Salesforce, we told the prospects to try both companies customer service and technical support. We knew we could resolve any customer issue before Salesforce would even respond.

Focus, domain expertise and awesome customer service —these are the hallmarks of great companies. Not the tech stack. Your moat might be more about who you are and what problems you choose to address. If you can conceive of it, AI can build it! Your vision, experience, brand, data and ability to execute may be more valuable than the software.

You Can Vibe Code Anything

As I think about my vibe coded music app Zudio, there is nothing to prevent someone else from creating a similar app. (I wish they would so I can stop working on it!)

Nonetheless, Zudio was #22 in the Music category over the weekend. (It must have been a slow week. It has since fallen in the rankings.) It’s a niche app that provides focused background music, so I’m not competing with Spotify or Suno.

What makes Zudio interesting to a listener is not how it was created but the human judgement and curation that went into making it. Yes, it was vibe coded in AI. But the styles, musical choices and instruments were chosen by a human. So if you happen to like the kind of music I like, you might like Zudio. (I was tempted to add a Math Rock style in tribute to Quebec rockers Angine de Poitrine, but I’ll leave it as an exercise to the reader.)

Claude wrote the code, but I designed the rules. Claude is good at detecting tonal clashes, and scale-adjusting notes, but not so good at knowing how to put together a balanced palette of instruments for Ambient music. Or that you can break the rules by using a buzzy FM synth with a filter sweep instead of a traditional bass and it still sounds good. I’m not saying AI won’t get there, but the most interesting work happens when you use AI as a collaborative partner and know what questions to ask.

As we enter a new era of AI generated software, experience, human judgement and design still matter. Maybe more than ever.

Zudio is available on the App Store for iPhone, iPad and Mac. With your help, it cracked the top 10 for Mac! Also, I promise to stop talking about vibe coding. At least for a while!

I found last month’s vibe coding episode interesting and fun. I shared the article (and the video blackjack game!) with a few people and got good feedback.

As impressed as I was with ChatGPT and Codex, I’ve seen many founders dismiss AI as suitable only for lightweight applications. A week ago, I had a bit of space on my calendar and decided to embark on a second more advanced experiment to see if I could get closer to professional quality development.

I’m going to take you on a journey of how I used AI to create a native Macintosh application called Zudio that generates new music. I’ll show you how I used AI, discuss the ups and downs of the project to highlight how software development is changing and the impact this will have on the industry. AI is not just a productivity boost, it’s opening up an entirely new field of software development.

Zudio: A Generative Music App

For the last several years, I’ve thought about building an application that creates music based on a set of rules, what’s known as a generative music system. Lacking the coding skills to tackle this project, it lurked in the back of my mind.

So I decided to turn this into test of how far I could get with AI. But I never expected to build a functional prototype in 3 days and a finished application in a week!

As a lifelong mediocre musician, I’ve always been fascinated by music technology. I used GarageBand to compose an open source rock opera with my buddy Rob. I’ve played guitar and bass in terrible bands. And I occasionally write electronic rock music.

Two generative music applications have captivated me: Reflection by the godfather of Ambient, Brian Eno and EON by electronic music pioneer Jean-Michel Jarre. They’re cool apps, but they are black boxes. You can’t shape the music in any way. Could I build a generative music app that gave me more control? I’m no Eno, but I met a guy named Claude who was eager to help!

The application I built, called Zudio, is well beyond my programming abilities. I don’t know Swift or SwiftUI, and I know just enough music theory to know a I-IV-V chord progression.

Although my taste in music skews more towards 70s rock (Beatles, Television, The Clash) I decided to build an app that creates Motorik songs in the style of Kraftwerk and Neu! You might not know the music by name, but you would probably recognize it if you hear it. It’s got a never-ending feel to it, like you’re driving down the autobahn at high speed in the dead of night. The Doors’ L.A. Woman is pretty close to Motorik.

Defining the Requirements

More importantly for this project, Motorik is decidedly formulaic. It uses the so-called Apache beat, a relentless 4/4 rhythm that drives everything. The bass locks in with the drums and not much else happens. Motorik songs usually stay on one chord the whole time to convey a hypnotic pulse. We used to play a classic Motorik song Hallogallo in the Duo Security band. We used to joke: If you could play an E chord, you could join the band.

Here are some typical prompts from the design stage:

Please analyze these Electric Buddha Band MP3s as potential examples: Time Loops, Dark Sun, Vanishing Point, Into The Night, Blakely Lab, Schulers Dream.

Would it be useful to run this analysis on other classic motorik songs like Fur Immer and Hallogallo? Please analyze Hallogallo, Neuschnee 78, Fur Immer, Seeland, and Wave Mother in the same fashion. In particular, I want you to try to derive rules for bass, lead, and rhythm instruments.

Now that the drum track is before the bass track, are there any additional rules for the bass player to follow the drum track? I want them to feel like a very locked-in rhythm section. Although classic Motorik such as Fur Immer or Hallogallo does not have much variation in the drums, I think for most cases it is better to have more variation so it is not too boring. Does this suggest any new rules?

Please carefully review the development plan and prototype docs, and any others, to determine what improvements could be made to these documents to increase the likelihood of success in the programming phase to create good code that can replicate motorik style music.

Rather than diving right into coding, I spent a couple days using ChatGPT 5.4 to undertake preliminary research and build the necessary requirements documents and plans. While ChatGPT did a great job on the video poker and blackjack games, for this project, it never felt like we were converging on music generation rules that were clear enough to translate into code. Undaunted, and with a self-imposed deadline looming, I fired ChatGPT and hired Claude Code (Sonnet 4.6) to take over. The new AI economy is nothing if not brutal!

While I don’t think Claude necessarily has a sustainable long-term advantage (feel free to argue among yourselves) it seemed more informed and decisive about what it was doing. It was like going from an intern programmer to a ten-year veteran. Claude ran agents to analyze classic Motorik songs as well as some of my own music to come up with the rules that would guide song generation. Then I asked Claude to assess the research and requirements to determine if we had enough detail. It deemed it ready to go. Who was I to argue?

Working Prototype in an Hour

The next morning I had Claude generate code. I’m always a bit nervous about the first build because a lot can go wrong. But with a few additional prompts, I had a working prototype generating music and displaying the MIDI tracks on screen like GarageBand does. It wasn’t good music, but the app worked, following the rules, more-or-less.

Personally, I had no idea how to display the generated MIDI tracks, scroll during playback, export to MIDI or any of that. But others do, and Claude knows how to apply their knowledge to my application. That is amazing. I have no idea where the design patterns came from, but with a few minor tweaks it was working surprisingly well. I could load MIDI files into LogicPro for further refinement.

I followed a traditional iterative process of development: Keep the build working, add one thing at a time and test the heck out of it as you go. I also had Claude continue to update the design documents as we built the application, capturing new rules and developing detailed plans for new features.

While it was impressive to get the scaffolding in place, the initial songs were weak. I had Claude build a status text area that served as a log of what was generated to give me visibility into what was working and what wasn’t.

SONG Dunkel Licht
Chords B Aeolian Static tonic: I Bm7, F#m, B7
Form Steady A section
MOT-DRUM-001 Classic Motorik Apache beat
MOT-BASS-015 Kraftwerk driving bass
MOT-PADS-001 Harmonia sustained notes
MOT-PADS-005 Harmonia charleston
MOT-LD1-001 Neu! motif first
MOT-LD2-003 Rhythmic Counter
MOT-RTHM-001 8th-note Stride
MOT-TEXT-001 Cluster sparse

When a song is played, the status area also shows when we enter each new section (A, B, bridge, intro, outro) and how parts are evolving (new bass line, drum fills, solos.)

You can regenerate individual tracks. For example, if the Kraftwerk-style bass doesn’t fit, I can generate a new one. I might get something more suitable, like a driving Giorgio Moroder bass line or a melodic McCartney part.

Quite often in playback, I could identify something was wrong with a rule and tell Claude to fix it. Then I asked Claude to create a secret test mode that lets me generate songs using new or recently changed rules. Piece of cake.

Here are some typical prompts during code generation and musical testing phase:

The music is now sounding much better. But as each track gets better, we are also starting to end up with situations where there’s so much going on it’s overwhelming: there are too many notes! I’d like you to come up with some additional guard rails during the generation phase, whereby if the lead, lead 2, rhythm and pads instruments all have a lot going on, you fall back to some alternatives to randomly reduce what’s going on in some tracks for some bars.

Here’s an idea I’d like to explore. Sometimes electronic songs will have a feeling of constant morphing as sound patterns evolve over time. So instead of playing one set melodic piece over all bars, the melodic piece changes over time, with small changes to the melody or the timing or both. That way it doesn’t get too boring. I wonder if we could do the same thing. have the bass part mutate with subtle changes, then in some cases evolve back. In other cases, restart from the beginning. What do you think of running some experiments on bass parts to do this?

I noticed that the bass pattern BASS-011 Kraftwerk Roboter was not evolving in a song. It stayed the same for 100 bars. Please double check that recently added bass patterns are subject to the existing evolve/devolve rules that we have used previously. Otherwise it’s too boring.

Also, when there is a three bar fill (and sometimes on a 2 bar drum fill) it is important for the bass part to still feel ‘locked in’ to that. So when we generate 2 beat or 3 beat drum fills, please update the corresponding bass part so it is in time with that. That could mean that the bass part has similar note rhythms to the drum fill (though less complex), or it could be that the bass part drops out (no notes) or perhaps plays its own fill in a corresponding rhythm.

Going Meta: Using AI to Test AI

Once we got the basics in place, it became apparent that I needed a more sophisticated approach. AI built the rules (with my guidance) so why not have AI analyze the songs themselves and identify the next set of improvements?

Not surprisingly Claude found even more errors than I did, including significant tonal clashes. Sometimes these were bugs in the code, e.g. Claude forgot to adjust song fragments to the current scale, and sometimes they were more subtle problems of two instruments stepping over each other. At any rate, rules were adjusted and new ones were created to ensure that the tracks were working together. With a couple of rounds of testing this way, the songs improved considerably.

New Musical Styles

Feeling pretty good with the results so far, I decided to push further by adding two new musical styles: Kosmic (Tangerine Dream, Jean Michel Jarre) and Ambient (Brian Eno) style songs. Each of these styles has its own distinct rules, structures, instrument choices and effects. Kosmic, the most complex style, took about two to fully research, analyze, implement and test. Having gone through the process twice already, Ambient music was more straightforward taking just a few hours.

Claude came up with generalized ideas about the songs (including popular keys, song structures, chord changes.) But to move from generalized analysis to good quality songs required coming up with instrument specific rules for each different track.

For example, I asked Claude to come up with a suitable Ambient drum pattern and appropriate instrumentation. If you run the app you might see the rule

AMB-DRUM-004 Claude hand percussion

I think it did a good job adding shakers, bongos, congas etc.

When I asked Claude how it came up with it said:

It was modelled on Brazilian/Afro-Cuban hand percussion as used in ECM-style ambient jazz — Brian Eno’s Ambient 4: On Land, Jon Hassell records, that kind of thing. The shaker-as-pulse with sparse conga syncopation over it is a classic texture that adds organic movement without imposing a strong grid the way a kick/snare would.

Better than I could do!

Things that seem difficult to me as an out-of-practice programmer, weren’t hard for Claude. For example, Ambient songs often don’t use a conventional tempo or beat, instead they evolve over time. Brian Eno originated this technique in the mid 1970s by stringing up magnetic tape loops of varying lengths, each playing a different part.

But just because mapping varying length loops onto a MIDI grid would be hard for me, there’s no reason not to have Claude rip off pay homage to that technique.

Looking Under the Hood

Though I’ve not read much of it, I suspect that the underlying Zudio code is a bit of a mess. Some of the tracks now have a dozen or more rules and each of those parts evolves differently over time. Occasionally, I’ve found weird bugs, like regenerating the drum track in Kosmic resulting in the same drum patterns every time. When I tell Claude to fix it, it does, but I have no idea whether the fixes are a good design or are just making things more brittle.

Periodically, when I noticed CPU utilization spiking, I asked Claude to optimize the song generation and playback loops.

There were a few times when I got quite frustrated. One is when I decided to add some new Motorik solos. I think neither one of us had enough understanding of the code base or musical theory to properly insert Pentatonic major solos into an Aoleian i-v chord structure. It took some trial and error to get there and to be on the safe side, I asked Claude to refactor some of the common code for transposing songs and adjusting scale before we attempted to add new solos for Kosmic and Ambient.

Nonetheless, it identified the sources behind some of the tonal clashes. Some notes were not being adjusted. So as I listened to songs, I found certain bass lines or solos that occasionally clashed. Then I told Claude to find and fix the issues. It turned out there are some hard coded notes used in some of the earliest generated bass parts. I’m not sure why that is.

When Claude tells me:

The b7 is +10 in Dorian/Aeolian but +11 in Phrygian, and doesn’t exist at all in Ionian — so +10 blindly applied is wrong whenever the chord isn’t a dominant 7th and the mode isn’t minor.

I have no idea whether this is true or not, but it makes sense to me.

When I asked Claude to explain why this particular bass track had the problem, it’s response was quite funny:

On why Vitamin Hook rule had hardcoded notes: The CAN “Vitamin C” bass line is a real, transcribed riff — Czukay’s original uses chromatic passing tones deliberately. The b3 (+3), tritone (+6), and minor 6th (+8) are in the actual recording. Whoever wrote that code was directly referencing the source material, which makes sense as a stylistic choice in Dorian (CAN mostly worked in minor/Dorian contexts). The problem is Zudio generates across multiple modes and keys — what’s a chromatic ornament in C Dorian becomes a genuine clash in E Ionian or another mode. The code assumed the song would always be in a minor-flavoured mode, which isn’t guaranteed.

The +10 b7 issues are a similar story — they were written with Dorian in mind (where +10 is always correct), and nobody checked whether the note lands in-scale for other modes.

Nobody checked!

In this case, Claude had found that particular song from its research, pulled out the bass line, created the rule and coded it.

This reveals an important difference between humans and AI. I caught the problem because I was actually listening. Something bothered me and I went looking for the cause. The AI had no way to know it should be bothered. It had written code that was internally consistent for the context it was designed for, and it would have gone on generating music with occasional clashes indefinitely, because nobody asked whether those notes would hold up across all keys and modes.

The AI can explain music theory, find bugs when directed and generate surprisingly good code. What it can’t do (yet) is notice that something is wrong. AI is a remarkably capable collaborator, but it needs guidance from someone with taste and curiosity asking the right questions and framing the work.

From my recent not-very scientific tests, Claude is better at this than ChatGPT, but it can still get lost if there isn’t a detailed plan and review cycle.

When In Doubt, Add More Rigor

The first time I tried to create a signed binary (one that is easily installable and verified free of malware) or when I changed the file save format from a plain text file to a plain text file with a .Zudio document type, it took a dozen attempts. Claude would happily tell me it worked, though testing proved otherwise. I suspect every noob Apple developer has problems with these tasks. Nonetheless, more detailed planning on my part (meaning asking Claude to verify in advance that the approach will work and implementing rigorous automated testing) would have helped.

Poorly defined requirements may yield working software that is hard or impossible to maintain. Those with domain expertise and a solid engineering background will have an advantage in using AI by likely being more thorough.

Zudio still has more randomization than musical coordination, so sometimes the songs sound great and sometimes not so good. Nonetheless, it’s good enough I can listen to it as background music, same as I do for other generative music applications. If I get time later on, I may pull in a more skilled musician with a better understanding of scales and modes to help me tune the rules further. I’d also like to add a continuous play mode and maybe an iPad version.

Once I had the App working reasonably well, I had Claude go summarize a proper explanation of the architecture and the design details for each of the musical styles. So if you want to nerd out on how AI came up with the rules for Motorik, it’s all there.

More Than A Productivity Boost

I asked Claude to estimate the effort it would take to create the docs and code without AI. What I did in 3 days of design docs and a week of vibe coding was likely 6-9 months of human effort –roughly a 15-30x productivity gain.

But AI is more than just a productivity boost. Vibe-coding is a fundamentally new way of developing software. I doubt I could have written this application in any amount of time. Vibe coding is opening the field to a new field of developers.

Plan-driven development isn’t new. But using AI to undertake what would have been a 3 week development sprint in a couple of hours is a remarkable transformation. Adding AI tools to verify the work and further improve the process takes things into uncharted territory.

As a new form of development, AI requires a different approach. Building strong specifications, whether by hand or leveraging AI is essential. When I strayed from this approach, for example by not specifying in detail how new solos work, or not researching how the Mac handles custom doc types, the results were mediocre. These problems were typically solved in under 30 minutes, but only because I was testing as I went along and enlisting AI to help with that work. It helps to have the approach of a disciplined programmer even if you’re not writing the code. Without that, you can easily end up with an application that is brittle and impossible to maintain.

The new emerging pattern is to use AI not just to do the work but to specify it, analyze it, test it and then improve it. You need to know when to use AI and when to hit the brakes and apply your own judgement.

Over the past six months, I’ve observed a kind of breakthrough that happens when people shift from using AI as a productivity tool to working with AI as a partner. In the latter case, they evolve their own approach to get better results.

Now Is The Time

Despite the rapid pace of innovation (and acceleration) in AI, I continue to meet CEOs who seem to view AI as just a “a nice to have” productivity boost. “Sure, our marketing guys use it.” Or: “I tried vibe coding. It can’t build an Enterprise grade app.”

For founders and CEOs this is a do-or-die moment. Either you’re embracing AI to do new things or you’re going to get run over by those who do. The disruption will come from someone who is brave or foolish enough to go all-in on AI, despite the current limitations. It might come from a 23-year old founder or a 55-year old greybeard, but it’s coming.

The effort required to build applications has been reduced so much that the traditional technical barriers to entry are gone. There are no technical moats. Not only can your existing competitors build your product in one tenth or less of the effort that you took, so can your partners and your customers. And even if they won’t, they can and will wield that threat in negotiations. And as the technical barriers collapse, so will the traditional high margins software companies have relied on.

The impact on the software industry is going to be profound. AI’s impact will be bigger than that of graphical user interfaces, the internet, open source software or mobile computing. Maybe more than all of those combined. The internet took fifteen years to go from an interesting curiosity (Microsoft bundled its first browser in 1995) to workplace and ecommerce dominance ($1b in Cyber Monday online sales in 2010.) The adoption of Ai and its rate of improvement are moving much faster.

But no one knows exactly how this will all unfold.

So my advice is it’s better to dive in and shape the future than to stay stuck in the past. If you want to have a white collar job 3 years from now, you’d better start using AI.

A good product manager or designer armed with AI has the power of a 24x7 development team that can build applications exactly the way you want them. Any application that uses known design patterns can be built with AI, whether it’s a CRM system or a music application.

As the barriers to development are lowered, there will be more software created. And as with any industry that has done away with gatekeepers, there will be a lot more bad software. Let’s face it, you can half-ass your way through anything with AI.

The tools are cheap and the technical barriers are gone. What isn’t free and can’t be automated is judgment — knowing when something is genuinely good versus when it’s just a facsimile. That gap is where AI shovelware will fail, and where people with discipline, taste and judgment will win.

The Zudio application is now available for iPhone, iPad and Mac on the App store.
Design documents, prompts, source code and an audio sample are available here: https://github.com/ZUrlocker1/Zudio#Zudio.

The latest version includes Chill-out jazz, Endless mode for continuous playback, a visualizer, fast audio export and more. These features went beyond the initial development timeline.

There’s no doubt that AI has improved more in the last three years than in the previous sixty-five. (Yes, AI has been around that long!) Anthropic, Google, OpenAI, Mistral and others have made huge strides in developing Large Language Models (LLMs) which are now able to ingest and manipulate data in ways that provide a massive productivity boost in a wide range of tasks.

One area that’s gotten a lot of attention in recent weeks is vibe coding, meaning using AI to program. With that in mind, let me share a couple of experiments and then try to answer a few questions:

• What is vibe coding like?

• Does it live up to to the hype?

• How will this change the way programmers work?

• What will be the impact on SaaS companies?

• Should you wait for the dust to settle or start using AI now?

Last summer, I decided to dip my toes into AI-assisted programming. I hadn’t programmed in years decades and my skills were rusty. Worse than that, I found the current programming tools overwhelming. There’s a lot of work required to get a modern IDE set up and integrated with a version control system to deploy in the cloud. After a few frustrating hours with more questions than answers, I gave up and decided to revert to a simple 1980s workflow.

Vibe Coding - Experiment 1

I booted DOSBox and Turbo Pascal 4.0 on my Mac and was ready to go. I’d written a shareware five-card Video Poker game for DOS and Windows back in the ‘90s called Tahoe5. Unfortunately, I’d lost the source code decades ago. But I was able to find an old DOS executable file which served as my spec.

I programmed a barebones text mode app, dropping into ChatGPT occasionally for assistance. Sometimes it would write good code, sometimes, not so good. Then I’d try to get ChatGPT to fix the not-so-good code and it usually made things worse. As a result, I wrote most of the code by hand.

I knew I’d written a woefully inefficient shuffle algorithm back in the day. So I asked ChatGPT to write a better one. It came up with the Fisher-Yates algorithm as published by Knuth in The Art of Computer Programming. It’s seven lines of coding elegance. If you’re going to steal, steal from the best!

I also asked ChatGPT to create some music routines for winning and losing hands. It responded quickly with code that looked good but didn’t actually, you know, compile. But it was easy enough for me to fix. Turbo Pascal compiled at 27,000 lines per minute on an 8MHz 8080 processor, so no problem!

I got the basics working quickly. Over a couple of days I wrote a more colorful user interface. It was about 600 lines of code and compiled to a 16k executable file in one second. Note that’s 16 kilobytes, not megabytes! It’s smaller than most icon files.

No one runs DOS anymore, so for laughs, I shared a screenshot with friends. It was useful to have some AI assistance, but it didn’t blow me out of the water. I was still doing most of the work.

While I would have liked to have built a mobile version of Tahoe5, the prospect of learning Swift, iPhone’s core graphics layer and Xcode seemed daunting. I filed it away under “Later” meaning sometime after I clean the garage, learn to play piano and publish a graphic novel.

Vibe Coding - Experiment 2

Then last week, I had an afternoon free and I decided to try the latest vibe coding tools with a buddy. I’d heard good things about Claude Code. OpenAI had just released Codex, which is a desktop app that automatically handles much of the donkey work by integrating with an IDE and a source code repository. It connects ChatGPT directly with VS Code and GitHub radically lowering the learning curve. That sounded good to me!

With a bit of guidance, I started typing prompts into Codex. I had it create a new VS Code project. Then I had it build a PRD for a five-card video poker game. As is often the case, the AI was more verbose than necessary. I asked it to revise the PRD based on my working Turbo Pascal code. Then I said to go ahead and build the app.

At this point, my expectations were low. The normal software development experience is that nothing works the first time. You have syntax errors. Or configuration errors. Or something that is so fundamentally broken you wonder why in God’s name you’re even working with these lame-ass tools and start to think that maybe writing a novel would be easier.

But after a couple of minutes of chugging along, Codex said it was done. I fired up a localhost web server and… It worked first time!

I don’t think I’ve had an application of greater complexity than “Hello World” compile and run out of the gate. I was impressed and a little shocked.

It was a double rainbow moment. What does this even mean?

And more importantly, how do I get AI to fix the graphics? They look terrible!

I asked Codex to create a nice looking card back, but all its attempts looked like Figma during a wi-fi outage. So I did it last-week old school, meaning I opened a separate Gemini chat and asked it to create a card back and then edited it in Pixelmator Pro. I pulled some face cards off the Interweb and added those as assets to the VS Code project and told Codex to use them as appropriate.

It took a dozen more prompts to improve the layout, adjust the graphics, change some fonts and of course, make the logo bigger! It worked well, with resizable panels and graphics that scaled for different size browsers. Total time: less than an hour!

Hoo-boy! This wasn’t just a mock up. It was a fully functional application that looked better than I could have written. I didn’t even read the code until it was finished.

There were about 700 lines of JavaScript and about the same in HTML and CSS files. I’m barely literate in JavaScript, so I asked ChatGPT to rate the code. It said it was solid hobbyist level code! That seems right to me.

ChatGPT didn’t think the code was enterprise scalable, which is what every senior developer says of a junior programmer’s code, so that’s fine. For a real world multi-user application, there’s more work involved and some of that may go beyond what vibe coding can do today. Real programmers do the hard work, not just the easy stuff.

The only problem was the layout was sub-optimal in a mobile browser. The cards were too skinny and some of the graphics were squashed.

I dreaded making the necessary changes for mobile knowing how this sort of thing usually goes. You’ve got something working and you know it has to change. But before you come out the other side, it’s going to go through several phases of broken.

So the next day, I told Codex to create a new version, in case I had to revert back. I gave it three prompts to rearrange the panels in mobile portrait mode and remove some unnecessary information regarding keyboard shortcuts which weren’t needed. That was it.

I told it to push and deploy the changes.

Again, it worked perfectly. Codex didn’t even break a sweat.

Just because refactoring code is an error-prone process for humans doesn’t mean it’s difficult for AI. After all, there are tons of code it can draw upon to optimize for mobile browsers. It’s not rocket surgery.

At this point there were a few hundred more lines of code. But I’m not working at that level anymore. I feel slightly guilty about this. What if the code is inefficient? Should I be embarrassed by Codex’s hobbyist level coding skills?

Vibe Coding - Experiment 3

Astute programmers and AI skeptics might say that my AI experiment wasn’t a challenge since I gave Codex source code to work from. To that I say, have you ever tried to translate Pascal code to JavaScript? It’s still work!

I remembered I had also coded a DOS and Windows blackjack game called Tahoe21. But I hadn’t rewritten it and there was no source code spec to work from.

My wife was out of town, so dedicated programmer that I am, I heated up some leftovers, fired up a documentary on Mel Brooks, and proceeded to half-ass vibe code my way to video blackjack.

I created a new chat thread in Codex and asked it to create a terse PRD for a blackjack game with the same style and play as Tahoe5. After a few minutes and some futzing with GitHub, I had another working prototype.

It had buttons for Double and Split. I had heard those terms but didn’t know enough about Blackjack to implement them back in the day. (Cough, I also had limited screen real estate.) I asked Codex to add the rules for Double and Split into the PRD in language a novice would understand. Then I tested those features. To no one’s surprise but my own, it all worked.

I spent a few more hours optimizing the user interface and screen layout. While it is unlikely you will ever have to deal more than five cards without busting, it can happen. So I gave Codex some prompts to re-arrange the cards when you get four or more. You can display up to eight cards on a normal desktop browser and six on a mobile. (Theoretically getting eight cards occurs only once ever 75,000 times, but it did happen a few minutes after I explained to my buddy the unlikelihood of this event. I’m still reasonably sure the AI is not listening.)

Codex handled it, letting me know this is called card fanning. Which just goes to show, it knows more about this stuff than I do.

Without much guidance the AI coded quite a few things on its own:

• Double and Split logic

• Randomized different musical tones for winning and losing hands

• Randomized taunts when the player runs out of money

• Secret test mode with different scenarios

To me the Secret Test mode was the most impressive. It devised (er, lifted) a test sequence that would run through various hands (Split aces, Blackjack, Dealer bust, Player bust, etc.) It can also be used as a cheat mode.

While the scaffolding of the app was solid, much of the user interface was weak. Most of the text in the app was more of placeholder quality than polished text.

• All of the status text had to be rewritten

• The About and Help screens were amateurish

• The layout of Split hands worked, but was cluttered on a mobile device

• Some of the screen drawing was off by a few pixels causing the cards to jump

• Layout of cards was too squashed

Optimizing for mobile required extra work as there’s less vertical space to accommodate the dealer, player and split hands. It required some more prompting and testing, but it eventually worked. Next thing you know the documentary’s over, my dinner’s cold, and it’s past 1am.

So it turns out vibe coding is a lot like coding. It’s fun in an addictive way.

PSA: Don’t Go Into Production!

For anyone thinking of going into production with AI generated code, please don’t. You should have a human review all code before going live. You don’t know what might be in there that could do bad things. (You wouldn’t know about the Secret Test mode in my games unless I told you or you reviewed the code.) You can bet that bad actors will be using AI in lots of creative and dangerous ways.

So what do I make of all this?

First of all, vibe coding is terrific fun! Apps like Codex make programming much more accessible. They take a lot of the pain out of using VS Code, GitHub, etc.

I reckon vibe coding is between 10x - 100x more productive. It’s like to moving from machine language to a very high level language.

In the 1980s when computers had limited memory, there was still occasion to write assembly language that could be more efficient than a compiler would generate. But ten years later, outside of writing device drivers or video games, no one bothered. Compilers got better, memory got cheaper and CPUs got faster.

We’re now transitioning from the plateauing Moore’s Law (chip density doubling every 2 years) to Huang’s Law (AI performance doubling every six months.)

So things should only get better from here.

But…

Just because I can vibe code a poker game in an hour doesn’t mean it’s the end of software development. That said, the nature of programming and the skills we need going forward are changing fast.

Much like the move from assembly language to high-level languages enabled more people to program, this will do the same. We might enter into a Jevons paradox, which causes demand for apps to rise because the cost of implementation is so low. Who knows, maybe we’ll see a flood of cheesy video poker games along with a slew of niche software applications.

So What Happens Next?

As Niels Bohr (or perhaps Yogi Berra) said: it’s hard to make predictions, especially about the future! But it’s clear that AI is a fundamental change in computing that will have massive impact on the tech industry, white collar work, education and society.

The change is likely bigger than the impact of the internet. But what makes it especially tricky is it’s coming 10x faster.

Twelve months ago, you could point to AI hallucination and say it’s not ready for mainstream use. I don’t think that’s the case anymore. Even six months ago vibe coding required a lot of manual editing. Today, not so much.

Normally, when a new technology comes in and automates or eliminates tasks, it also creates opportunities for new roles. So while coding an app can now be automated, surely product management, design and testing will become even more valued human skills. Unfortunately, I’m afraid it’s turtles AI all the way down. There’s no reason to believe that AI won’t do a better than average job on these tasks in the near future. If you’re not well above average, your job is toast.

When things are changing rapidly and there’s a risk of massive disruption I believe it’s better to be a steamroller than a bystander on the pavement.

If you’re not using AI in your work, now would be a good time to start. It may be tempting to wait until things settle down. But “wait and see” leaves you in the worst possible place. Better to start working with today’s less-than-perfect tools so you develop an understanding and help shape the future.

For those early in their careers, this is an opportunity to become an expert. No one has 10 years experience in vibe coding. Heck, almost no one has six months experience! So if you start now, you will have more experience than most. Someone will become the “AI expert” in your department. It may as well be you.

This is the one time that being young works to your advantage. You’ve got less to re-learn and (hopefully) less resistance to change. At the very least, schedule a few days every month to try out the latest tools by using them on real projects. If you have to pay for ChatGPT or Claude out of pocket, it’s a cheap investment in building expertise. Luck is what happens when opportunity meets preparation, so make sure you do your part.

Not only is AI getting better, but humans are also getting better at using AI. So share best practice tips with colleagues. If you’re not sure where to start, fire up ChatGPT, tell it about the work you do and then ask where you can use it. If your company doesn’t allow you to use AI, do it on your own time, on your own dime. Then get a new job as fast as you can.

As the saying goes, AI might not take your job, but someone using AI certainly will. You don’t want to be the old man in their front yard yelling “But the old way is better” when the whole world is moving to AI. And believe me, they are moving.

Does this mean the end of apps? Will we just have one Super Agent that runs everything in some Minority Report pre-cog app with a massive touch screen? Maybe not. But I bet there are teams at Google, Apple, Meta and Amazon that are trying to figure that out.

To the extent that life is modal, there will be ongoing desire (if not need) to have software applications that do specific things. Yes, more and more apps will have an AI agent user interface or at the very least, AI behind the scenes.

Will companies all code their own Enterprise applications? That’s a scenario many people are wondering about. I think it’s unlikely. For companies with a lot of data in the cloud or a SaaS app, migration is a massive undertaking. But certainly there will be price erosion and margin compression. If you’re paying a few hundred bucks per employee for certain productivity apps, that may still be worthwhile.

Some companies will decide that $100 a month per person for Salesforce (or realistically, Salesforce + Google Apps + Zendesk + Hubspot + dozens of others) is just too much and they’ll vibe code their way to something. Building a prototype is easy. But building in-house applications also means a commitment to ongoing maintenance for the rest of your life.

If you vibe code a “quick and dirty” CRM app, expect another ten feature requests from every user who has an opinion. Building internal apps is like giving someone a puppy… you still have to take care of it!

More likely, I think we’ll see new competitors come out with quite decent suites for lower prices. Maybe Salesforce isn’t worth $100 per user per month. But is a fully functional CRM worth $50? Or if it’s the last day of the quarter how about $25?

If you’re a in software company more than five years old and not “native AI” you should assume there are teams vibe coding a new competitor ready to launch. Better for you to build an internal AI tiger team to reinvent your business than get disrupted from the outside. Executives of every function (Sales, Marketing, Finance) need to get hands-on experience with AI to understand what it can do in their field. Showcase the early adopters in your organization so that everyone benefits from their learning.

The Hybrid Opportunity: Augmented AI

The last time there was a hint at this kind of disruption was with open source software, which is essentially free, in the early 2000s. Companies like Red Hat, MySQL and JBoss were able to disrupt incumbents by offering good quality with a promise of reliability and service for up-to 90% less than the big guys.

Somewhere between the destruction of SaaS multiples and the world of super agents that do everything, there’s an opportunity for companies to manage the new thing through a combination of AI + people. Call it hybrid mode, human-in-the-loop or Augmented AI. For many companies it may make more sense to pay someone to manage their AI applications and infrastructure than to do everything in house.

Firms that can manage the complexity of AI for their clients and distinguish themselves by delivering great service will have an opportunity to thrive. Smaller companies are almost always able to do this better than larger incumbents.

It’s an exciting time and it’ll be interesting to see a new crop of companies that leverage the power of AI to do great things. Who’s in?

Apologies for the long post! What are your experiences with AI? Are you vibe coding? Creating new proposals? Generating designs? What’s working? Leaving a comment!

Two other great article on this subject: Matt Shumer’s Something Big Is Happening describes the recent acceleration of AI and Stephen O’Grady’s Besieged has a nuanced discussion of the build vs buy dilemma and the economics of AI. Both are worth reading.

Click to try the Tahoe5 and Tahoe21 applications. Source code is available on Github. If someone wants to build a native iphone or Mac version of these, let me know!

When you work in a startup, it can feel like you’re in a constant state of flux. If you’re in a high growth company (tripling or more year over year) it will feel like new company every six to nine months. You’ve got different customers, sales channels, products and competitors at every new stage.

Incremental change, such as a new market segment, new sales territories, a new pricing level is easy for most people. But when you make a change in strategy that can be harder. Especially changes like:

• New product

• New positioning

• New market segment

• New business model

Or all of the above when a company undergoes a major pivot.

Station to Station

Strategic changes are by their nature more disruptive. They have the potential to change the trajectory of the company and the careers of those involved. But only if people get on board. If you don’t manage the transformation, you might find that internal resistance or indifference slow things down.

Unfortunately, you can’t just make a grand pronouncement in a town-hall meeting and expect that everyone will “get it.” No matter how clearly you’ve articulated the logic, people will gravitative back to their old ways. Yes, of course there’s the new thing, but I’ve still got my old job to do!

If you don’t manage people through the change you can lose weeks or months to the status quo.

The early days of Duo Security were fraught with change. As with many companies, there was constant pressure to get new features out. Usage had grown quickly over a couple of years and as we added more large customers, peak usage exceeded our capacity. We suffered a couple of server outages which tarnished our prior 100% uptime track record.

Is It Any Wonder?

The problem arose through suboptimal decisions made by independent teams. New trial users were all placed on one server, known as Duo1. Once they became paying customers, the customer success team was to move them to other servers in a round-robin fashion. Unfortunately, because there was often minor re-configuration required on the customer’s side, many large customers were not moved.

The result was a steadily increasing volume on Duo1 while other servers were well below capacity. The concentrated workload resulted in multiple outages on Duo1 impacting a disproportionately large number of customers. Sometimes the most damaging problems in scaling companies aren’t caused by bad decisions—they’re caused by perfectly reasonable decisions made in isolation.

While Duo’s early customers (many of whom were themselves startups) might be tolerant of an occasional brief outage, larger enterprise customers would not.

This required rewiring the organization to understand that our priorities had to change. I worked directly with Chester Kustarz, the head of Engineering, to solve the issue. Chester was a phenomenal leader and he understood the technical and organizational challenges. While we were all somewhat embarrassed of the outage, that wasn’t going to fix the problem.

I joined Chester in a meeting with his direct reports and team leads. I knew people already felt bad about the outage. In my experience there’s nothing to be gained by getting mad or blaming people for the sins of the past.

Instead, I emphasized that our newest customers, including hospital doctors, could be locked out of systems during an outage. What happens if they can’t prescribe the drugs that are needed during an outage? Everyone understood the severity. We had all used products that started off great and then grew bloated or unreliable over time. We didn’t want Duo to end up like that.

We Can Be Heroes

This established a clear emotional reason for why we needed to do a better job. We had to do right by our customers. Chester listed all the feature priorities for the quarter. And at the top he wrote “P0 - Reliability.” This was our new priority.

A hand went up from one of the team leads. “But what happens when the founders ask about our ship date for the next release?” It was a good question because it brought forward an underlying fear many of the Engineers had.

“If it takes us 30 days to make the product more stable, that’s the time we will spend. I have your backs. And I will push back on the founders to let them know this is necessary.”

“But what happens if it’s more than that?”

“Don’t worry. If it’s 45 or 60 days. I will push back.” Then I smiled. “But if it’s 90 days, we might have a problem.” We still had pressures in the market and I wanted people to feel a sense of urgency.

Chester scheduled a follow up meeting with a larger group where we brainstormed ideas. Not every idea was necessary or practical. We later met with the managers to pare it down to a dozen subprojects that would have the highest impact. By working in the open we got more good ideas and more buy-in than we would have had otherwise.

The next stage was the trickiest. We had to make sure that people got moving on the new initiatives. It’s surprising that people can intellectually understand a need for change, they may even be emotionally motivated to change, but the practical matter of actually changing their behavior can easily get bogged down in day-to-day reality.

It’s not because people are trying to undermine the change, it’s that they still have existing obligations and projects that were started before the strategic change.

So what Chester and I did was meet with every engineer to review what they were working on and help them to wrap up their old work as quickly as possible so they could get started on the new tasks. They could have a day or two to clean up and check-in their existing code. But we were clear that this change in priority around reliability was not just some abstract concept. Their work had to change to support it.

I have found that this last phase of change is the often neglected resulting in wasted effort and expensive delays. You train sales people to sell a new product, but as soon as they get a prospect meeting scheduled they go back to demoing the product they are already comfortable with. That’s just human nature.

In some cases, you need to absolve people of feeling bad for leaving one project, perhaps not quite finished, in order to start on the new thing. Sometimes it helps to acknowledge that you’re putting an existing project into a state of “benign neglect.” Most importantly, people need to know that even if things aren’t perfect, they won’t get in trouble for working on the new thing.

Rebel, Rebel

In larger organizations, you won’t be able to meet with everyone, so you need to identify other agents of change. You may need to build a tiger team of believers who are excited about the new thing. Maybe there’s a sales person who’s ready for a new challenge. Maybe it’s just a couple of engineers who want to work on something new. The most powerful teams are those filled with passionate believers. And likely, you may need to operate outside the normal organization structures.

When we launched a new subscription version of MySQL, we couldn’t get buy in from the head of Sales. He liked the existing license model and didn’t want to distract his team. So we found one sales rep who was willing to give it a go. We got a couple of engineers on loan and one marketing person to help build the initial subscription product. Only after our cowboy sales rep closed a few deals did others start to believe in the new model.

The more radical the change, the more likely you will find opposition from internal leaders. If someone has spent ten years building a SaaS business, they might understandably be skeptical of the ability of AI to replace it. This scenario plays out every time there’s a platform shift and it’s one of the reasons agile startups are able to disrupt larger incumbents.

The best way to win over skeptics during a transformation is to operate with high transparency sharing every win, every loss, and every lesson you learn along the way. At Duo Security we put up a sign that highlighted how many days of uptime we had without incident. Our new reliability initiatives were given significant airtime in all-hands meetings, so people could see reliability was valued as much or more than new features.

As you share progress, share the spotlight, too. Let individual contributors, rather than executives, speak to their work. They will have more credibility with their peers than any top down announcements.

Change is never easy. It takes way more effort than you expect. But if you follow this approach, you’ll get more people moving in the right direction than if you just announce the change and hope for the best.

If there was one constant in David Bowie’s career it was change. His 1976 greatest hits compilation album ChangesOneBowie was a seventies rock classic. Though many artists stick with a proven formula, Bowie continued evolve well into his, ah, Golden Years.

As companies grow beyond the first couple of dozen employees, alignment often starts to fray—not because people aren’t committed, but because the implicit culture of the founding team no longer scales. New hires bring different backgrounds and assumptions. Departments begin to form their own perspectives. Engineering questions how Sales positions the product. Roadmap debates harden. Side conversations multiply, and teams gradually drift into silos. What begins as normal growing pains can quietly turn into a drag on execution and morale.

Sometimes things are moving so quickly that you don’t notice teams are out of alignment until the situation boils over and you start losing employees or missing dates and revenue targets.

Poor alignment can stem from a confluence of several issues:

• Lack of clear strategy

• No plan of execution

• Weak accountability

• Poor communications

In an early stage startup, you may get by without alignment because there’s a strong implicit culture among the founding team. You’re focused on building features, closing deals and moving as fast as possible. You may be moving so fast that you don’t need to think about how decisions are made. They’re just made quickly by the founders with whoever is in the meeting and then letting other people finding out later via slack or email.

As you hire more people, things that are implicitly understood by the founders, may not be understood or followed by new hires. When you’re growing quickly, you will likely hire experienced executives to help scale. But if you don’t let them make decisions, it can lead to frustration on both sides. Having a strong executive team and alignment on goals, values and plans is key to scaling.

Whenever I join a high-growth company, I tell the board or the CEO that I will be an agent of change. And if they didn’t want change, they shouldn’t hire me!

Sometimes, the problem is that the operating principles that worked well in the early days no longer fit as the company grows. Maybe you’ve sold to early adopters via a Product Led Growth (PLG) model and now you want to sell to Enterprise customers. Or perhaps new competitors have stepped in with a weaker product, but stronger sales and marketing.

How should you respond?

There are lots of different ways to address this, but if you don’t have alignment at the executive level, you’re going to have a sub-optimal solution. And when the executives are not in alignment, it will only get worse further down the organization.

You need to get everyone moving in the same direction. Good companies respond to opportunities and evolve. They develop a strategy and execution plan that pulls people together and drives progress. The trick is to agree on the goals and then let leaders make the decisions. In other words, once you’ve agreed on what’s important, let departmental leaders manage how things get done. After all, that’s why you’ve hired them. Good leaders don’t want (or need) to be micromanaged.

Often alignment splinters when there are multiple conflicting views of how to proceed. Sales has one view of the situation, Marketing another, Engineering a third. Everyone comes with their own experiences, ideas and biases. It’s great to have input from many areas. Diverse views can result in better brainstorming and better solutions. For complex decisions, you must focus on what is best for the Enterprise, rather than for any single department.

Trust and Accountability

The two key issues are trust and accountability. When you hire experienced leaders, you must trust them to do the job they’ve been hired to do. You should also have prioritized quarterly goals so that there is clear accountability.

The best way to foster these two points is to promote a high degree of transparency in all areas. That means setting clear goals and plans for every department, with no “black boxes.” Adjacent teams (e.g. Sales / Marketing, Product / Engineering) should collaborate to define goals and plans together.

Once goals and plans are defined, leaders need to respect that their charges will deliver. You cannot allow second-guessing. Otherwise, you are undermining the progress of the company. You must commit to supporting your colleagues in their decisions. Instead of saying “it’s not how I would do it” try saying “How can I help?”

MySQL CEO Marten Mickos used to joke that for complex problems, the decision would get made by whoever would get the blame if things went wrong. Although that’s kind of a dark Scandinavian humor, what it actually meant was: whoever has responsibility makes the decision.

Here are 5 tips that can help improve alignment:

• Build an annual plan that defines the top level company initiatives. This should include new products, new expansion plans and other big strategic bets.

• Require written annual plans for each department. These don’t have to be lengthy, but they must identify not only their departmental objectives, but also what they will do to support the top-level company initiatives. These plans should be shared across all departments to increase transparency.

• Make executives from adjacent teams work together on their plans. For example, Marketing and Sales must be in agreement on what segments and use cases will be targeted.

• Ensure that departmental offsite meetings include participation from adjacent groups. For example, the Sales Quarterly Business Review (QBR) should include participation from Marketing and Product.

• Communicate the top level initiatives and progress towards the goals in every all-hands meeting.

Fast growing companies always have a certain amount of chaos as you figure out the right positioning, features, go-to market model, pricing, etc. At the same time, you also have to build the internal processes that govern how complex decisions get made.

Having clear ownership and accountability can help increase alignment not only at the executive level, but throughout the company. It takes discipline and constant communication to keep people focused on the top priorities. But if you do it right, everyone will come together in harmony.

Many people will recognize the image at the top of this post as the album cover for the classic Beatles album Abbey Road. There were several alternate photos from the same shoot, but none capture the spirit of all four in alignment like the cover photo.

In the early days of a startup, it might feel like you’re unstoppable. You may have a 60% or higher win rate with many deals uncontested. But if you’re truly in a good market, someone’s already looking over your shoulder and wondering how to beat you.

The market was pretty stagnant when Zendesk launched the first cloud-based help desk product. Legacy on-premise vendors were completely stalled. After a couple of years (and high-profile rounds of venture investment) we faced quite a few up-and-coming competitors.

This was a bit of a shock to the founders who were used to being the up-starts and getting all the attention. Now others were coming after us! Worse still, having turned down a $200m acquisition offer from Salesforce, they then acquired one of the up-starts, Assistly, for $50m. Our suitor had turned into a well-funded competitor!

While it’s easy to get obsessed with competition, don’t worry about their game, worry about yours. The most important thing is to plot your own course. In the case of Zendesk, we had our strategy and roadmap and there was very little we needed to change from a technical perspective. After all, these competitors were imitating us!

We knew that our cloud approach made it easy for companies to get started and dramatically improve their customer service. It put power back in the hands of customer service teams and enabled them to do a better job for their customers. Zendesk beat the heck out of traditional IT ticketing systems and on-premise solutions.

Still, getting a kick in the pants from the competition was good for us. We got more aggressive on pricing. And we used Salesforce’s size against them since we could move much faster than they could. Later, we modernized our user interface to make Zendesk easier and more responsive.

We heard from many customers that although they couldn’t always tell which software would best serve them from a trial, we proved to them our customer service was superior and that was often the deciding factor.

When you face competition there are two important things to understand:

• What is it that makes you unique?

• How can you use the strengths of your competitor against them?

Lead, Don’t Follow

When you face a larger competitor, you must not get lulled into playing by their rules. If you’re competing with legacy vendors, you must figure out a way to disrupt the traditional buying process. This might mean focusing on underserved markets often with different buying criteria. If you are simply reacting to the competition, or copying their approach, you’re unlikely to win.

Zendesk didn’t try to copy legacy Enterprise strategies. Instead, we targeted new emerging markets, small and medium businesses, game companies and high-growth startups that didn’t want to run traditional on-premise software.

Later on, at Duo Security, I saw how futile copying was when RSA, a much larger Enterprise security company, cobbled together a Duo wannabe from several acquired technologies. Their product was a mess. But it validated our approach and cemented our position as an industry leader.

Competitors may be larger, they may have bigger marketing budgets and more salespeople. As a startup you can (and must!) move quicker and develop a better understanding of emerging market opportunities. The bigger, more entrenched your competitors are, the more likely they are to be hampered by their existing playbooks and bureaucratic processes.

You will have to work harder, ship faster, take more risks and try more things in order to identify specific use cases and segments where your product is a better fit than the competition.

You must know in your heart why you will win and you must do everything possible to create a clear and compelling message that shows that you not only understand your customers problems but you have a long-term vision. You won’t win every deal, but you will be much more effective by telling a story that is grounded in your understanding of the market.

Don’t Drive With One Foot On the Brake

There will be times when the reality of your product may not match the vision you’re selling. While you cannot succeed with vaporware, don’t limit your story to the present.

Technical founders sometimes hesitate to sell the future because they fear overpromising. But that hesitation is a brake on growth. Talking about future capabilities may make the most technical people inside your company nervous.

That’s ok.

If you’re not making people a little nervous, you might not have sufficient ambition. Most customers want a vendor who can be a long-term partner and they are as much buying into a vision and roadmap as they are the current set of features.

If you can paint a compelling picture of the future and deliver the features your customers need today, that can be a winning formula. Focus on what makes you different and better, whether it’s your architecture, scalability, ease of use, implementation time or something else. Then build out a roadmap and target uses cases that enhance your differentiation in ways that matter to customers. Don’t compromise on what makes you uniquely you.

Winning isn’t about outspending or out-talking competitors — it’s about knowing what makes you different, staying faster and closer to customers, and selling a vision that pulls the future toward you

One of the things that has always been surprising to me is how few companies build a customer-focused organization. Companies like to talk about it, but few deliver on the promise.

As a startup, this is one of the areas you can truly differentiate your product, services and your whole company: make customers a top priority. You won’t be bigger than the big guys, but certainly you can deliver better service, faster than they can.

In the early days of a company, it’s pretty easy to reinforce this. If you regularly talk about progress with customers and how important is to be responsive, employees will get the message and follow along. If they hear a founder talk about how we closed a deal by quickly implementing a requested feature or going the extra mile, it becomes self-reinforcing. After all, who doesn’t want to get a shout-out in the next all-hands meeting?

But as you grow and add more layers of management, objectives by department, you start to dilute the exposure people have to customers. Sales, and customer service are generally plugged-in with customer needs. But over time, even groups that should have access to customers, like engineering, product and marketing, often don’t because they are heads-down busy trying to deliver on their objectives.

Ironically, companies with high volume product-led growth (PLG) are often the worst at understanding their customers. They might have thousands of people buying from them online, but the better that PLG machinery works, the less interest there is to hear from and understand the needs of specific customers.

As a result, high-volume companies are at risk of understanding everything about their customers except what actually matters: why did they buy from you and what else do they need?

Towards A Customer-Centric Culture

The metrics you gather in a PLG business --product usage, how to optimize the trial period, predictors of churn, identification of expansion opportunities —are all super interesting. But it’s important to occasionally step away from the dashboards and talk to customers.

And by “talk to customers” I actually mean: Invite them to talk and then listen. It’s amazing how much you can learn by asking customers basic questions:

• Why did you buy from us?

• Who did you compare us to?

• What was the critical thing that got you over the line?

• What else could we do that would be helpful?

You should also talk to prospects where you didn’t win. Not to talk them out of their decision, but to better understand where you missed the mark. (Generally speaking, you usually need to give this a few weeks after the deal has been lost so that you get more than just a polite “don’t want to hurt your feelings” brush off.)

If you have the humility to ask, you can uncover powerful ideas that can help unlock further growth. You might find there are certain misconceptions about your product or areas where your competition is able to deliver value quicker. And often it’s not the hardest, most sophisticated features that win deals. Sometimes it’s about how easy you make it for customers to undertake routine, mundane or error-prone tasks.

Take it all in and consider: how can you better leverage your strengths and reduce or eliminate your areas of competitive weakness?

As your company grows, you’ll need to take conscious steps to build a customer-centric culture. Here are five ideas that can help.

Bring Customers to Your All-Hands Meetings

One of the best ways to shape your culture is to invite customers to your all-hands meeting, whether that’s in person or remote. You are putting your customers front and center for the entire company to see. Invite them to talk about how they’re using your product, what they like, what they dislike, and how it fits into their overall technology strategy. Then open up to questions from anyone in the company.

I guarantee if you do this regularly several times a year, you will increase customer empathy throughout the organization. People will remember these customer sessions far more than most of what is discussed.

Everyone in Marketing Writes Case Studies

One of the most powerful pieces of marketing content you can create are customer case studies. While it’s always a complex dance to get customer approvals, I have found that there’s huge value to building a case study pipeline and knocking out two or three every quarter. After a couple of years not only do you have a large library of reference customers, but you will also be enriching your team.

The trick is don’t just farm case studies out to an external agency. Instead, rotate the duty across all areas of marketing. There will be some bitching and moaning from people who are unaccustomed to this kind of work. But if you create an interview template and ask them to write a first draft before it goes off for polishing, you’ll be amazed at how much stronger your marketing becomes. Messages start to resonate more, positioning becomes stronger and people are fired up after they talk to happy customers.

Product Marketing and Product Management Should Have a Customer Quota

The more customer exposure the product team has, the better your roadmap will resonate with customers. If product marketing and product management aren’t out regularly meeting with customers and hearing about what problems matter most, you’re just guessing at product / market fit. You might stumble across it, but it’s going to be more luck than anything.

Founding engineers often have a lot of pride around understanding early customers and perhaps claiming with some accuracy that they understand the market better than anyone because they are the market. But as markets expand, your ideal customer profile is likely to change. Later adopters are usually looking for a more complete solution than early adopters were willing to put up with. For this reason alone, it’s important that product marketing and product management are keeping a pulse on what customers and prospects are looking for and thinking about.

I’ve found it helpful to make sure the product team is out regularly listening to customers and sharing their observations back with Engineering and the rest of marketing.

As the market grows and attracts competition, remember that today’s unique differentiation can easily be copied by others. By increasing their exposure to customers and prospects the product team can keep their pulse on how customers are perceiving the competition and help you identify additional adjacent problems that might be worth addressing.

Send Engineers to Trade Shows and Conferences

While Engineers might grumble about attending trade shows and conferences, I’ve found that it can be highly motivating for them to see how customers respond “in the wild.” As a side benefit, sales, SEs and marketing can learn a lot when they hear directly from Engineers explaining to a customer how something works.

If your company has an Executive Briefing Center or Customer Advisory Board those can also provide great opportunities for engineers to hear directly from customers and prospects. Customers often appreciate the ability to explain their problems directly to engineers without a lot of layers in between.

Cross-Pollinate Departmental Offsite Meetings

Because Sales, SEs and Customer Success teams often have the most customer exposure, I recommend inviting someone from one or more of these group to help represent customer perspectives in departmental offsite meetings. This can help shorten the time to validating ideas. It can also increase confidence in roadmap planning.

Building a customer centric culture requires conscious focus. It doesn’t just happen on its own. Maybe what I’ve proposed will spark even more creative ideas that will fit your company.

When companies faces difficult times, as they most certainly will, the answers can often be found by going back to basics: what do customers need? It helps tremendously if those skills have been honed throughout the organization. But remember, your culture is greatly influenced by the actions that come from the top. Don’t talk the talk unless you walk the walk.

I remember one brilliant executive that I worked with years back. The company had acquired a competitive product line and gradually lost interest in maintaining it. Whenever pressed about investing more in the product his response was “Where else are they going to go?” I don’t think I ever saw employees at that company go the extra mile for customers. Why would they?

What ideas have you seen that help build a more customer-centric culture? For those curious, the image at the top of this post is from the terrific band Crack The Sky. It was the cover art for their third album Safety In Numbers, from 1978.

Lately, I’ve been mentoring some early-stage startups. Some have a minimum viable product and a few customers, others are still working on the underlying science of their offering. They are all pre-seed, surviving on funding from the four F’s: founders, friends, family and fools.

This stage is one of the toughest because you’re caught in a chicken-or-egg dilemma. You don’t yet have enough traction to raise serious capital. But without capital, it’s hard to finish the product or win the customers you need to show traction.

A startup, at its core, is an innovation in search of a business model. And finding that model takes time, iteration, and a lot of work before investors are ready to write meaningful checks.

The Traction Paradox

Many first-time founders get stuck at this initial stage. They believe that if only investors gave them money, they could move the business forward. That may be true, but unless you’ve already built successful companies, investors want proof before they invest. The exact proof isn’t as important as the principle: venture investors need evidence of momentum.

Here’s the part that doesn’t get said enough: every stage of a startup is hard.

I like to compare it to running marathons. When you sign up, you know you’re choosing something difficult. You train with the understanding that the suffering is part of it. I ran marathons for ten years, and I reminded myself during training, that I was preparing for race day one mile at a time. Every mile repeat, every hill meant less suffering on race day.

The same is true in startups. The more you understand your customers and their problems, the fewer needless detours you’ll experience while building your company. But no matter what, there’s no such thing as an easy startup.

Every startup I’ve been part of has had its share of ups and downs: missed quarters, product delays, outages, new competitors, customer churn, internal drama — you name it. From the outside, successful startups look like a straight line of growth. On the inside, it’s always messy.

As an early stage founder, you must

• Build a team

• Get product / market fit

• Grow to the next stage without running out of money.

One thing that can help you focus your efforts is to think of your startup as passing through a series of gates. While there are lots of twists and turns along the journey, you must focus on exactly what will move you from the current stage through the next gate.

At the pre-seed stage, you might convince friends or family to invest because they know you and you’re an expert in a specific domain that has helped you identify a significant market opportunity.

At the seed stage, you need to show that you can execute on the vision by delivering a working product to happy customers.

At series A, investors want to see proof there is product/market fit. For a B2B company, that’s typically crossing the $1M revenue threshold along with evidence that there’s a large overall target market. For consumer apps, the yardsticks are different: perhaps 100,000 monthly active users with strong daily engagement.

At Series B and beyond, you need to prove you can build a profitable business. You want to show accelerated growth, improved margins, and the ability to scale the operations beyond the founding team.

Also, keep in mind that investors are not customers. They care more about your business than about the features or patents you have under development. You need to show more than just a product strategy. You need a compelling business strategy that shows you can expand revenues, distribution and margins over time.

Focus On Your Current Stage

The lesson for founders is simple but not easy: you don’t get to move to the next stage without proving your way. You’re moving from proof of concept, to product/market fit, to scalable operations. For investors, each gate you pass through is reducing the risk on their investment.

You need to figure out how to get momentum at each stage through creativity, hard work, salesmanship, luck or all of the above. No investor is going to rescue you.

In fact, investors are looking for exactly that combination of determination and creativity that enables founders to keep going no matter what obstacles arise.

Don’t make the mistake of trying to optimize for tomorrow’s problems today. In particular, it’s easy for technical founders to get caught up in building advanced features before getting customers into production. When your number of users is in the hundreds, investors will not care that you have an automated multi-region failover architecture that uses the latest open source technology.

Get Things Working, Optimize Later

There are many things you must do to get the things off the ground in the early days that are not necessarily scalable when you have a $100m business. That’s okay as long as you have a plan to improve it later. Don’t try to optimize everything from the get go. The most important thing to consider is: will it help you to move to the next stage?

For example, early customers might require a lot of technical handholding and unanticipated product workarounds to get them into production. That might not be very efficient with your first batch of customers, but once you understand the issues, you can figure out how to optimize for the next batch.

While it’s possible that the first version of your product or service is perfectly correct, it’s likely that you’ll need to change over time as the market evolves and customer needs change. A successful startup is one that is constantly experimenting and improving.

When things are hard, when you’re really not sure how to proceed, have the humility to meet with customers and prospects. Ask them about the problems they have. Listen carefully. And consider whether you are solving the right problems.

It’s easy to fall in love with your product ideas. But what matters most is that your customers fall in love with your product. If it’s not happening, consider what problems you could solve that would most excite your customers. (Hint: ask them!)

Remember, while no startup is easy, none have ever died from too much customer focus. The surest way to get your business to the next stage is to build it one customer at a time.

For companies that are beyond Series A and have product market fit, you want to be thinking about how you can systematically make operations more efficient every quarter, every year. Look for ways to reduce friction in the organization, whether it’s in the customer acquisition process, sales cycles, customer deployments and so on.

It requires conviction and hard work to adopt a mindset of continuous improvement but it is much better than the opposite.

The picture above was from the Bayshore Half Marathon in Traverse City, Michigan. Anyone looking for a flat, fast Spring marathon PR should consider it.

Sometimes in early stage startups after you close a few deals you figure you’ve checked the box and can start scaling. Because now you’ve got that everlasting Product / Market Fit that your investors have been hammering you about. But are those early deals really representative of the market? In some cases they might be one-off custom development deals or as a result of founders calling in favors within their network.

There’s nothing wrong with that. It’s a good way to get feedback and exposure. But it can create a false dawn. It looks like daybreak, but that faint glow on the horizon is just dust particles in space. It’s noise, not signal. Founder-led sales are not particularly scalable. Founders carry a certain charisma that regular sales people might not be able to pull off. Prospects might feel obliged to listen to an intro through their board. You get a polite reception and then… they’re just not that into it.

The best way to think of product / market fit is as a continuum, rather than a binary, one-time event. As your business grows and the market evolves, you will enter new market segments where you will need to continuously prove your value. Having adoption among European tech companies doesn’t mean it’ll play in Peoria, and vice verse. New market segments have their own distinct requirements and buying processes.

Crossing the Enterprise Chasm

In the early days of MySQL (and Zendesk and Duo Security and pretty much every Enterprise software company) we were excited to book meetings with large Enterprise customers like GE, American Airlines, PeopleSoft and Siebel Systems. No doubt, they were ready to buy. I mean, why would they book an in-person meeting if they weren’t serious?

So we scrambled to build an Enterprise Edition, staff an Enterprise sales team, create an Enterprise pitch deck and so on. And we learned the lesson that every Enterprise software company learns: Enterprise sales are slow and complicated!

Ironically, when we built the Enterprise sales team, there was a lot of envy among the existing mid-market sales reps who were vying for those roles. Everyone anticipated the commissions that million dollar Enterprise deals would deliver. Three months later, when the Enterprise team hadn’t closed anything, the mid-market reps figured they’d dodged a bullet. Six months, later the Enterprise reps were wondering if they’d committed career suicide.

We eventually figured things out and built the required features that Enterprise customers needed. These went well beyond the requirements of our early adopters. We started closing larger deals, but it took a lot perseverance and maturation of our product, services and approach. It also took time for Enterprise customers to trust open source enough to use it for mission-critical applications.

The key lesson is that selling to mid-market companies and high-growth startups didn’t mean Enterprise customers were ready for us, or that we were ready for them. Each new segment you target has its own specific requirements. Having product market fit in one segment doesn’t guarantee success in others.

Enterprise customers have far more complex needs in terms of integration, reporting customization and security. It’s not enough to “do the thing” for Enterprise customers. You’ve got to integrate with their existing systems, provide the reporting they want and prove the value. Unlike smaller companies who are willing to work around your product limitations, Enterprise customers are looking for a “whole product” that can be integrated into their existing operations.

As you develop your go-to-market strategy, you should understand what product or service capabilities you need to add to expand into specific market segments or territories. In effect, your product roadmap is the key to expanding your reach to unlock new use cases and new segments. Each new release should give you some competitive advantage that opens up a bigger slice of the market.

Are You Ready to Scale?

Premature scaling happens when investors (and sometimes founders) are so impatient for growth that they mistakenly assume that success with a few customers means the company is ready to double or triple overnight. On a spreadsheet, it looks so easy, it’s hard to argue. But in the real world, ramping up sales and marketing before you have product-market fit can be a frustrating and costly distraction.

The best way to counter this, is to make sure you really have a repeatable, efficient process before you staff up. Here are a few questions to consider:

• Can you define your ideal customer profile?

• Do you understand the key personas involved in the purchase and the specific problems they are trying to solve?

• Do you understand their buying process and the approvals required?

• Can you explain how your product is better than competing solutions?

• Can you reliably predict which prospects have a higher likelihood of closing?

• Can you efficiently engage high-likelihood prospects through marketing?

• Can you close prospects without calling in favors or dropping your price?

• Can you get customers into production in a predictable and reliable process without calling on Engineering for custom work?

While you don’t need to have a perfect answer to every one of these questions before you scale your business, an honest assessment should help you determine how repeatable things really are and where you need to improve. You should be able to point to specific customers in production and show how they are representative of your go-to market strategy.

If you don’t have good answers to at least five of the above questions, you should spend more time trying to uncover patterns among your prospects that will help you improve your targeting and strengthen your understanding of the problems they have.

As with the most complex challenges in life, product / market fit is an ongoing process. In rapidly evolving markets, there can be changes in market conditions (new competitors, new customer expectations, new technologies) that knock you back a few steps. When that happens, get out and talk to customers. Understand their problems, listen and learn.

It’s a Numbers Game

Also recognize that when it comes to product / market fit, quantity trumps quality. The more at-bats you have, the more wins under your belt, the easier it is to identify repeatable patterns. Those patterns might not represent a majority of customers, but if you can consistently target them and close them, you should double down on that bet.

Sometimes there will be multiple patterns that emerge, each one occurring 12 to 20% of the time. You will need to think about what marketing approach, content and product features matter most to each of these groups. It might be that there’s a class of prospects who are frustrated with a competing product. Or it could be pressure that is being felt in specific market segments around a particular common problem, whether that’s seasonality, shopping cart abandonment, cost-cutting or some other scenario. You want to go beyond generic “one-size-fits-all” communications to focus on what really matters to the buyers in each different segment.

If you can identify prospects who fit into these patterns and speak to the value you provide, you are on your way to building a truly scalable business.

The picture above is not dawn or false dawn (I’m never up that early), but it is one of my regular running routes at Timbers Recreation Area in Traverse City, Michigan.

What happens when you gather 12 ambitious founders on a remote private island in the Finnish archipelago for 3 days near the summer solstice? It’s either a Fourth Box bootcamp of intense learning or the ominous start of a cult murder mystery.

Over the past few years my friends Clint and Marten from MySQL and I have mentored dozens of founder / CEOs as they build exciting startups in open source, SaaS and cyber security. This spring we decided to run a 3 day bootcamp for top-notch CEOs on a remote private island in the Finnish archipelago. We even shared the storied origins of the Fourth Box.*

It took a leap of faith that we could get a select group of venture-backed CEOs to travel to a remote location and secure sponsorship from top-tier VCs so that we would not lose our shirts. I am grateful to Benchmark Capital, Index Ventures, LifeLine Ventures and Scale Venture Partners for their timely sponsorship and nominations.

Until I stepped off the boat and onto Fagerholm island and met all of our CEO participants in person, there was still some doubt in my mind that we could pull this off. So much of an event’s success depends on the personalities and participation of the attendees. In this respect, our first cohort was superb. They were self-aware, engaged, ready to share their challenges and eager to learn.

Did it work?

Yes, absolutely! But that’s just my opinion as one of the organizers. More importantly, we exceeded the expectations of the participants and delivered real value.

We asked the participants to rate the experience on a scale of 1-5 :

• The FourthBox CEO bootcamp was a good use of my time. (Score 4.875)

• I would recommend the CEO bootcamp to other CEOs of similar companies. (Score 4.75)

We asked participants to share feedback on what they learned that they can apply in their company. Here are a few of the comments (slightly paraphrased):

• I was impressed how much people opened up. Most valuable for me was when we broke off in smaller groups and discussed our specific challenges. I learned how others are running their executive team meetings and this gave me new ideas I can put into practice.

• I learned some good ideas on how to run internal QBRs with sales, marketing and product to review deals we won or lost. This will help us increase the feedback from sales into the product team.

• It was interesting to hear how other companies are using AI internally. It was valuable to take a step back and reflect on this.

• Lots of reflection on my own leadership style from exposure to peers.

• I learned ways to enable my team to step up as leaders so I can focus on the most important items for the company.

• Good take aways to create more urgency in the team.

• I just talked to my head of people ops and we will experiment with some of ideas I stole to improve internal feedback.

We also asked what should we keep or do more of:

• The location was amazing. I think that environment was critical for changing the typical performative founder persona.

• I would keep the location exotic as it makes it easier to learn new things. I would also keep focus on workshop / discussion style rather than lectures.

And some areas that we could improve:

• I wanted to hear more from coaches and long-time CEOs who had done it before.

• It would be good to be able to sign up for a 1:1 on a topic with a specific coach.

• I’d recommend a more narrow range of companies in terms of funding and revenue. I learned the most in discussions with founders at similar stages.

It was an interesting, high-intensity approach to mentoring. While everyone left excited (and probably exhausted) the real test comes in the weeks, months and years that follow. It’s easy to go to an offsite meeting and come away with dozens of ideas. But it takes discipline to apply new techniques and best practices to improve your own performance and that of the team. We will be following up with the participants next month to help with that process.

To me there were a few key takeaways that made the event successful:

• Though it was hard to get to, the remote location contributed to the high level of engagement of participants. There were no distractions, and no other people on the island —only FourthBox participants and Fagerholm staff. We were in close quarters, sharing meals, saunas and sleeping quarters from sunrise 4am to sunset 11pm. You could not achieve the same level of openness and engagement in a hotel in Napa.

• The participants were chosen in part for their humility and willingness to learn. This was not the stereotypical Silicon Valley alpha male CEO group. We had a diverse set of CEOs (9 men / 3 women, 6 from the US / 6 from Europe) which helped keep things balanced and open. There was also a wide spread in the maturity of the companies from pre-product market/fit (sub $1m) to $50m in ARR. In retrospect that was too broad a range and we frequently broke into subgroups based on size / maturity.

• We had a high ratio of mentors (3 men, 2 women executives) each with different areas of expertise.

• We had a lightly structured program with designated topics and leaders. This enabled us to kick off discussions and then zero in on the topics the founders wanted help with. We were also able to pivot (“pivot!”) when necessary.

• There were a couple of hours of down time each afternoon enabling people to catch up on email, phone calls, seek one-on-one meetings, go kayaking, relax or engage in other activities.

• There were no board members, investors or other employees involved, which enabled people to open up more than they might otherwise.

I hope that we will do this again next year. There are definitely improvements we can make to get more in depth, practical discussions. But considering this was our first time running a CEO bootcamp, I think we did quite well.

And of course, mentoring is not a one-way street. All of us, including coaches, learned from each other. It’s interesting to hear how a younger generation of founders think about technology, business and the world. This is the first large group of “AI native” founders that I’ve worked with and their ambition and creative drive is inspiring.

Perhaps most gratifying was the feedback from one of the attendees:

• I’d love to pay it forward some day!

There is no greater demonstration of leadership than planting ideas that others make their own.

(*) The legend of the Fourth Box was revealed in a secret ceremony on the final evening after much partaking of alcohol, saunas and cold plunges. But if you really want to learn that story, you’ll have to get nominated to join our next cohort.

I am grateful to Clint, who convinced us to hold the event in Finland and to Marten who found a wonderful former coastguard island in which to host our inaugural event. The location was a challenge, but it was the catalyst for opening people up to new ideas.

I also want to thank our guest mentors Anna Binder and Kelly Battles who brought creativity and passion to topics that many founders struggle with around building a strong culture and creating accountability. Also kudos to our local host, Alto University undergraduate Casimir Rönnlöf who made sure everyone made it to the island and had a first class experience.

I recently held a Q&A session with Michigan-based founders and the first questions were: What did working on the business look like for you during Duo Security’s growth? How did that evolve as the company scaled?

This is one of the hardest challenges founders face. What is the right balance between working in the business and on the business? You’ve absolutely got to deliver results every month, every quarter. If you don’t build the new features, you can’t attract more customers. If you can’t get enough new customers, you can’t raise money. If you can’t raise money…

Understandably, when a company is in its earliest stages there’s a lot of pressure to lean in and operate in founder mode to get things done quickly. Sometimes you just need to make the decision, write the code, close the deal.

But in order to scale a company, you’ve got to also build the systems and processes that enable you to close more customers and higher revenues next quarter, and the quarter after that, ad infinitum.

It’s a cliché, but it’s an apt one: you’re building the plan while flying the plane.

If you’re a founder or an executive (or aspire to be one) it’s not enough to deliver results. You must be making the business better every month, every quarter, every year. You can’t just work in the business, you have to work on the business.

A certain amount of chaos is unavoidable in early stage companies because you need to discover a path toward product / market fit. You cannot predict exactly how customers will respond to your product, your positioning, your pricing and so on. So the likelihood of getting it perfect is quite low. Instead, you need to be sufficiently agile to try things, observe the results and refine as you go. It requires deliberate experimentation.

It’s good to have regular review periods where you look back to consider what is working and what is not. It sounds simplistic, but often the best thing you can do is cut the things that aren’t working and double down on the things that are. Startups need to move quick, so if something isn’t working after 60 or 90 days, you don’t need to prolong the experiment, just make the call and try something else.

Ideally experimentation and learning become baked into the culture of the company. That means you have to measure results and accept that not everything is going to work.

It can be useful to review pipeline or deals weekly or monthly to understand what patterns are emerging and what new lessons you’ve learned that can improve execution.

Scaling at Duo Security

When we were doubling and tripling at Duo Security, I was always clear to the leaders of different functional areas that our sales growth didn’t mean that their particular teams or budgets would grow at the same rate. After all, we needed to improve our margins in order to get to profitability.

So, as an example, when working with Lisa Paul, our VP of Customer Success, I was clear that her team needed to get more efficient every quarter, every year. (Because if you’re not doing that, you’re getting worse, which is untenable!)

Of course, the number of customers, implementations, support tickets, would all double. When you don’t have the option of doubling the team, you need to get creative. Lisa Paul’s job as the CX leader was to make sure we could identify and operationalize improvements. Every quarter she would review the top ten customer support issues and take action.

• Get Engineering to improve those features so they were less error prone

• Create documentation to guide people through complex configuration options

• Develop videos or training content that to show best practices

• And so on…

Instead of just doubling the staff, a focus on efficiency forced us to be proactive rather than reactive. Sure it’s more work, but it is work that ultimately made us better. The result was we continuously improved our operations and thereby increased our customer satisfaction. Duo’s Net Promoter Score was routinely around 70 (Apple territory) and far above most SaaS companies. Most of the staff enjoyed working on projects which got them out of the daily grind of responding to customer support tickets.

Too Much Process?

In the early days of Duo (or in fact most successful startups) you’re going to reinvent the company about every nine to twelve months. The types of customers you sell to, the competitors you face, the leadership challenges will be changing and you need to evolve along with it. So just how much process should you create?

If you don’t put in place enough process, you end up stuck in reactive mode, constantly firefighting with little time to think about how to improve operations. But if you put in place too much process won’t that impede agility? Quite likely.

I have seen startup companies fossilize in their early stages by thinking that once they had $5m in revenues, they had perfect product/market fit. They then hired big company executives to maintain the status quo.

The executives were well meaning, but they’d never been at a startup during periods of rapid growth. They were brought in to maintain things and eke out 20 percent growth every year. The way you do that is you put more safeguards in play, more control and then you grind out more and more efficiency. Optimize pricing and consumption and renewals and don’t let anyone color outside the lines. It’s a perfectly acceptable playbook for a mature company. And it is precisely the wrong play for a startup.

In a startup, your goal is to add “just enough” process so that you can continue to improve, but not so much that it impedes your ability to listen to the market and try new things.

Getting Better All The Time

The goal is to build a lightweight, just-in-time process. The first time you put together a customer proposal, it might be a scramble, pulling in multiple people already busy with other tasks. The second time you do it, you might be able to streamline decision making and make it 10-15% easier. The third time, it should be a template-driven, repeatable process. That’s not to say every proposal will fit within cookie-cutter constraints, but you want enough process to efficiently deal with the most common elements.

Whenever you join a startup, there are things that are broken and areas that can be improved. Scaling is the art of fixing things so that they can continuously improve. Your goal is to get to the next stage of growth ready to evolve even further.

I have found that as organizations grow, you can get a lot more scale by leveling up middle managers and ensuring that they are making decisions, developing action plans and communicating effectively. They’re closer to the action than executives and many rise to the challenge when given more accountability.

If you need to close every deal or make every product decision in the first twelve months of the company, so be it. But if after that first year you don’t figure out a way to get yourself out of the critical path on these tasks, you might want to consider spending more time working on the business rather than in it.

What are the tradeoffs you’ve seen in working in the business versus on the business? How much process has been right for you? Share your comments below.

When founders complain about “growth problems,” I usually nod politely and ask a few questions. “How often are users coming back?” “What’s your activation rate?” “What do people love about the product?” Nine times out of ten, it turns out they don’t have a growth problem at all—they have a product problem.

And if you’re honest, you might too.

I’ve seen this cycle across dozens of early-stage companies: a promising launch, a bit of press, a burst of traffic... and then crickets. The founders blame marketing, or “awareness,” or some mythical GTM channel they just haven’t cracked yet. But the truth is, users aren’t sticking because the product isn’t delivering enough value—at least not fast enough to matter.

This isn’t meant to shame you. It’s a common trap. In fact, it’s a rite of passage. But escaping it means shifting your mindset from “how do we get more users?” to “why don’t the users we have care more?”

Let’s unpack why this happens—and how to fix it.

The Myth of the Growth Hack

Startup culture has romanticized the growth hack: the scrappy, clever trick that suddenly drives tens of thousands of users. Dropbox’s referral loop. Airbnb reverse-engineering Craigslist. Facebook opening up to Ivy League schools.

What most people miss is that those tactics worked because the underlying product was already valuable. Dropbox solved a painful sync problem. Airbnb unlocked extra income. Facebook scratched the deepest itch of all—status and connection.

If your product isn’t creating value, no amount of growth hacking will save you. It’s like trying to scale a leaky bucket. You can pour water in faster, but you’re still leaking at the bottom.

The best growth strategy at the early stage is a great product that solves a real problem better than anything else. Period.

The Retention Litmus Test

Here’s the hard truth: if you can’t get 10 people to love your product, you won’t get 1,000 to like it.

Too many founders are chasing scale before they’ve earned it. They’re paying for ads, launching on Product Hunt, trying to optimize onboarding flows—meanwhile, their churn rate is 70% in week two.

Focus on retention first. Not vanity metrics like DAUs or signups—real retention. How many users come back after the first use? How many after the tenth? Are they using it because they love it, or because they have to?

If your retention is weak, your job is not to grow—it’s to understand why.

Talk to every single user. Watch their sessions. Ask what they were hoping for when they signed up, and whether the product delivered. If not, what was missing? You’ll learn more from ten in-depth user interviews than from a thousand new signups.

Find the Aha Moment (Then Accelerate It)

Every great product has an “aha moment”—the point when users finally get it. They feel the value. They shift from testing to using.

For Slack, it was sending a few team messages and seeing how fast and fluid it felt. For Notion, it was building a workspace that was less cluttered than Google Docs and more flexible than Trello.

You need to find your product’s aha moment—and then design your onboarding, activation, and early UX to get users there as fast as possible.

This might mean cutting features, simplifying flows, or rewriting all your copy. It’s worth it. Because until users hit that moment, you’re just another app.

Track how long it takes users to reach your aha moment. Then ask: how do we cut that time in half?

Value First, Monetization Later

One of the biggest mistakes I see is over-optimizing for monetization too early. Founders fret over pricing tiers, free trials, and upgrade paths—before they’ve proven their product delivers enough value to be worth paying for.

It’s backwards.

You don’t earn revenue by gating features. You earn it by solving problems. If your product saves someone 10 hours a week, or makes them more money, or helps them sleep better at night, they’ll gladly pay.

Until then, focus on value. Get people using it. Show them results. Then ask for money.

This doesn’t mean giving everything away for free forever. But early on, your priority should be proving indispensability—not maximizing ARPU.

Nail a Niche Before Going Broad

Another trap: trying to be everything to everyone. Your product supports sales teams, marketers, developers, teachers, dog groomers… and no one loves it.

Start narrow. Pick a user segment that really feels the pain your product solves. Go deep into their workflow. Obsess over their needs. Make something so useful that they become your evangelists.

Most great companies started this way. Facebook was just for Harvard students. Salesforce was for salespeople. Shopify was for indie e-commerce stores.

Find your beachhead. Dominate it. Then expand.

Metrics That Matter

Let’s get tactical for a moment. Here are the metrics you should care about at the early stage:

• Activation rate: What % of users reach your aha moment within the first session or day?

• 7-day and 30-day retention: How many users come back? (Cohort analysis is your best friend.)

• Engagement depth: How often do power users use the product? What features do they touch?

• Referral/word of mouth: Are users telling others? Why or why not?

Don’t get distracted by surface metrics. Focus on signals of love, usage, and value.

The Brutal Simplicity of Value

Here’s a harsh but helpful framing: people only use products that make their lives better. That’s it.

If they’re not using your product, it’s because it doesn’t solve a painful enough problem, or it doesn’t solve it well enough, or it’s too confusing or slow or clunky.

Fix that.

Go back to first principles. Who is this for? What do they need? Why is this better? Test ruthlessly. Iterate fast. Cut what doesn’t matter. Polish what does.

Great products are simple, but getting there is anything but.

Build with the Few to Reach the Many

The early users who stick around, give you feedback, and push your product’s limits—they’re your co-founders in spirit. Treat them that way.

Build features for them. Fix their bugs. Get on Zoom calls. Obsess over their use cases. They are your best early signal of product-market fit.

When you make those users successful, two things happen:

1. They spread the word, organically.

2. You discover what real value looks like—which you can then scale.

It’s tempting to ignore the “few” because you’re dreaming about the “many.” Don’t. The few are the path to the many.

Final Thoughts

Startup success isn’t about velocity—it’s about direction. You can scale all the wrong things and end up nowhere fast.

Before you chase growth, make sure you’ve built something worth growing. That means solving a real problem for real people in a way that feels 10x better than the alternative.

If you’re not sure you’re there yet, good. That means you’re asking the right questions. Dig in. Talk to users. Ship changes. Be relentless.

Because once you do build something people love, growth gets a lot easier.

Not easy. But easier.

So back to the question: Can AI help you improve product market fit? Maybe it just did! I asked ChatGPT to write this post in my style. How did it do? Let me know in the comments below.

In early stage companies, marketing is sometimes a misunderstood and underinvested area. Especially if the company is engineering led and selling to other engineers. As a result, the marketing can come across as generic features and benefits for a generic audience. “We’ll let the product speak for itself, we’ve got 1,000 stars on GitHub.” That’s a great , but it doesn’t mean you’ve got sustainable product / market fit.

While tech companies sometimes get initial traction positioning as “by developers for developers” sooner or later you’re going to want to expand your scope. Are you selling to all developers? Specific types of developers? For what kinds of applications? What about their managers?

Marketing operates at multiple intertwined levels. At the broadest level you have strategy and competitive position. Next, is your ideal customer profile or target company. When you get into actually selling a B2B product or service, things get more complicated. Because you’re not just selling to a company, you’re selling to the people in that company. And different people can play different roles in the purchase decision reflecting their goals, ambitions and fears.

If you’ve ever found yourself in a debate about what it is that customers want, having a more precise view on customer personas can help cut through the noise.

A persona is a representation of the different people involved in buying or using your product. Yes, you could have Dave the developer as one of the personas. Dave might represent the guy who is giving you GitHub stars. He’s a classic early adopter who likes to learn new technologies and wants to make a name for himself as an innovator.

But Dave doesn’t work in isolation. His boss, Mary the Manager, might be the person who decides what software goes into production. And she’s been burned betting on startup technologies that didn’t deliver. If you don’t figure out a way to get her on your side, you might find your deal sidelined.

Marketing isn’t a “one size fits all” communication. You have to tune your message to the needs of the different personas in your buying process.

In the early days of selling two-factor authentication at Duo Security, our customers were pretty typically network IT administrators in mid-market companies tasked with securing internal systems. They weren’t security experts and they wanted to get an easy-to-use solution up and running quickly. Duo’s 30-day free trial and detailed online documentation made it easy for them to configure, test and deploy a solution fast. Most customers were up and running within 3 days. We developed a reputation as the easy solution.

As the company grew, we expanded our product line and our ambition to sell to larger Enterprise customers. However, as anyone who has done Enterprise sales knows, we encountered more feature requests and more complex sales cycles. We had to be SOC-2 compliant. We needed to integrate with a broader range of single-sign-on products. There were also more requests for more reporting. Government customers were asking for FedRamp certification. At the same time, we didn’t want to lose our mojo, the ease of use that made us successful with mid-market and small business customers.

During a period of rapid evolution and growth it’s easy to get confused about who your target customer is. Sometimes the things Enterprise customers ask for are at direct odds with the needs of small and mid-market customers. And you’ve only got so many engineers. That can lead to a lot of conflicting inputs across in product, engineering, marketing and sales.

To get clarity, we built out more detailed personas. The design team led the charge and they became adopted broadly across the company.

Our earliest personas were based on interviews with real customers. We looked for common characteristics, roles and problems they faced in using security tools. We had Gary the IT Administrator and Helen, the Chief Information Security Officer. Helen was based on a the CISO of Ohio State University, which, football rivalries aside, had become a large customer. We also had Henry the Helpdesk Specialist. And because Duo was widely deployed in organizations, we identified Lee as our prototypical user.

These personas provided clarity to Product and Engineering as they built the roadmap. They could speak clearly about the benefits of specific features designed to help Gary, Henry or Helen or Lee.

These personas also improved the focus of our marketing communications. We could identify campaigns and content that was intended for Helen the CISO as distinct from Gary the IT Admin. Helen was thinking strategically about the organizations overall security posture, cloud adoption, mobile device policies and reporting. Gary was more focused on day-to-day operations and specific technical integration capabilities. If the rollout of two-factor integration didn’t work, or if users got locked out inadvertently, he’d get the blame.

I knew our persona strategy was working when I saw printed copies of the of the personas with pictures of Helen and Gary on the wall in different departments of the company. It was a good reminder of who we were serving.

When we spoke about our customers we no longer spoke generically. There was now much greater understanding and empathy toward the different roles people played and how they used our product. Would the new reporting help Gary? Is Lee going to understand how to configure and use a new feature? Discussions were based less on opinions and more about how to do right by the different personas.

Personas increased everyone’s understanding of customers across the organization and gave us a useful and shared framework for making decisions.

Thanks to Pete Baker, founder of the digital agency FinalFinal for his contributions to this article. Pete was previously Head of Design, Brand and Creative at Duo Duo Security and a huge champion of personas.

One of the most important rituals in a startup is the all-hands meeting. This is when you gather all the employees in the company, whether in person or via video, and pontificate about the future. Ok, maybe that’s how all-hands meetings go in some companies, but that’s not what you’re aiming for. A properly run all-hands meeting provides direction and leadership to the team and gets them excited about the mission.

There are obvious occasions to have an all-hands meeting, such as when you are about to launch a new product, have raised new funding or undertake a change in strategy. But all-hands meetings shouldn’t just be for special occasions.

In most cases, once a company has passed the implicit culture hive mind of about a dozen people, you need to spend more time communicating. The all-hands meeting can be an effective way of making sure everyone is up-to-date with the latest progress and priorities.

You should hold these meetings at least quarterly, and for early stage companies with a rapid pace of change, a more frequent cadence can be helpful to keep everyone aligned.

If you’ve ever wondered why people are off strategy, not quite doing what you hoped or making sub-optimal decisions, it could be that as things have evolved, the latest strategy updates or priorities are not making their way to all employees. There can be a lag time in communications or, like a game of telephone, the message is garbled as it gets passed through second or third-hand.

A well run all-hands meeting is an amplifier of leadership. It gets everyone on the same page, hearing from the leaders of the company (whether executives or not) and addressing the hard issues.

Repeat The Message

You may find yourself repeating the same messages in every meeting, but in a growing company, it’s better for people to hear the priorities too often than not often enough. You’ve got to repeat the key messages over and over again. In marketing, there’s an adage that it takes seven impressions before someone will buy from you. Why would your employees be any different? Just because you’ve sweated over the quarterly objectives and priorities don’t assume that everyone else has absorbed them.

Another important element of the all-hands meeting is it enables you to demonstrate and celebrate the company values.

At Gatsby, we ran the all-hands meeting every two weeks for 60 minutes. The exact agenda would rotate depending on where we were in the quarter and what was going on, but it included topics such as:

• Welcome of new employees to the company

• Celebration of internal promotions

• Employee nominated peers demonstrating one of our core values

• Demonstration of new features in development

• Upcoming product launch plans and marketing campaigns

• Celebration of a major new customer win or expansion

• Recap of an executive or departmental offsite

• Analysis of customer satisfaction trends

• Feedback from and Q&A with customers

• End of quarter results against goals

• New goals for the new quarter

• Update on funding strategy

• HR topics such as benefits programs, reviews, etc.

As you can see, there’s no dearth of topics can be covered in the all-hands meeting. Often the challenge was keeping the meeting to 60 minutes. (Yes, we frequently ran over time.) Even during the toughest times, the all-hands meetings always provided more energy than it took.

The most important thing to consider is how to keep your audience engaged. If you’re conducting the all-hands meeting remote over video, you’re already at a disadvantage. Presentations can be informative, creative, challenging, inspiring or silly —but they can’t be boring!

We were fortunate at Gatsby that our VP of Operations, Maddie Wolfe, was the host and emcee of the all-hands meeting. Even during the worst times of the Covid lockdown, she kept the meeting lively and interesting.

In any rapidly growing organization, there is way more going on than can be covered in a single meeting. I have found it helpful to have a deep dive (15-20 minutes) on one or two topics in each meeting, rotating regularly between different departments and speakers.

Starring Individual Contributors and Customers

Even though there are other many ways to disseminate information, when properly run, the all-hands meeting has a number of benefits. Employees hear updates directly from those involved. They can ask questions to help them understand how to apply changes in strategy. And they are excited to see the work of their teammates and colleagues get recognition.

In case that last point isn’t totally clear, make sure that the all-hands meetings include presentations from individual contributors and frontline managers, not just executives. Let’s face it, after you’ve heard from a third random executive in the company, most people are tuning out. But when a peer is presenting work that they’ve been involved with, they are hanging on every word. That’s how you build audience engagement.

The other thing that can be helpful is to pull in customers. People never tire of learning how customers are using your product or service in the real world. Sales and customer success teams can also be quite effective in sharing customer stories. Customer stories often have far more impact in shaping the culture and focus of your company than any top-level mandates.

Sometimes when difficult topics are being addressed, there can be a reluctance to allowing audience questions. Personally, I’ve always appreciated people who ask the hard questions of management. That said, I’m not in favor of anonymous questions since they lack accountability and hinder constructive dialogue.

When someone does ask a hard question, there are likely others who have the same question but were uncertain how the question would be received. So whatever you do, don’t shoot the messenger! Even if the question is off-base, don’t dismiss it. Recognize the legitimacy of the question and consider why it’s being asked. Acknowledge the underlying concerns and answer as a teacher would, with authenticity and compassion.

As the company grows, departmental meetings likely will become more important to employees and so it may make sense for all hands to be monthly, quarterly or somewhere in between.

What topics and techniques have you seen that were most impactful in company meetings? Post a comment below and let me know.

Most of my career has been as an operating executive, but I have also been an advisor and board member to venture-backed software startups. It has been helpful to see the inside of another company, the challenges they face and consider what lessons I can apply in my own work. It is also gratifying to help younger companies avoid common strategic and execution pitfalls.

As a rule of thumb, you should try to get your materials to the board at least three days in advance, and preferably seven. Depending on the timing of the meeting and the size and complexity of the operations, you may not have the final financial statements if the quarter has just closed. But you should still strive to get the materials and draft financial statements to 90% accuracy. Most board members would rather have an early read on how the company is doing in advance of the meeting than wait for perfect information in the meeting.

One troubling trend I observed with one company was the ever-growing scope of the board deck. What started out as a long twenty or thirty slide deck continued to grow every quarter. There was the CEO’s summary of how the business was doing. There were detailed slides on sales performance, often with four or more competing bar and line charts showing one team’s performance compared to another, based on win rate, deal size, sales cycle and so on. There were even more details on average deal size by geography, product, new sales versus expansions. More slides on gross renewal, net renewal, by segment, by product line, by geography. And slides on quota attainment, by geography, by team, by segment. If there was a number, it was reported, usually in several different ways.

At some point, the board deck grew to 117 slides. It was as close to “death by PowerPoint” as is legal in the state of California.

Analysis Paralysis

The irony was that despite the company’s detailed analysis of their performance through every lens possible, they never hit their numbers. In fact, if you weren’t paying attention, you might not have even noticed that.

To me the problem was not one of analysis, it was execution. The inordinate amount of analysis inhibited management from improving sales execution and product differentiation, the two most likely culprits. Sometimes the diagnosis is not to be found under a microscope, but by talking to the patient.

Instead of endless slicing and dicing of numbers, it’s better to ask more fundamental questions:

• When someone buys from us, why do they do so?

• What situations do we see where we have a higher likelihood of winning?

• When we lose a deal, what does the customer do instead?

• What could we do to better differentiate our product?

• Are there new capabilities that would expand our appeal in the market?

Any time I see a massive board deck, I cringe at the cost to the organization. The larger a company gets, the more scrambling there is. It’s not uncommon for a finance team to spend two to three weeks putting together board materials.

No matter how detailed the reporting, a good board will ask questions that have not been answered. Often this is because they are trying to be helpful to tease out a line of thinking that they want the management team to pursue.

In time tested max of “shit rolls down hill” an off-hand question by a board member can turn into days or weeks of reporting by sales managers and the finance team. And once it’s been memorialized in a board deck, it tends to become a standard requirement for all future reporting, regardless of whether anyone is still using the information.

When I’m on a board, I tell the CEO and management team I want to see the reports that they use to run the company. I’m not looking for them to undertake new reporting for the board.

Of course, if it’s an early stage startup and they don’t have good reporting, then it’s easy to go overboard with an extensive list of what mature companies do. But remember, a startup is not a mature company, it’s an experiment.

What Matters Most: Product Market Fit

In the early days what matters most is finding product market fit and repeatability. Some analysis can be helpful in finding repeatability. But product market fit is not something to be found through analysis. It’s either obvious you’ve got it, or you’re not there yet. That said, product market fit can be a bit like falling in love. Sometimes it hits you where you’re not looking.

In the early days of MySQL, we had quite a few small web startups using our software. This was one of several interesting patterns we saw in the market, along side our software being embedded into applications, and a few forward looking Enterprise companies trying to decrease their dependence on Oracle. It was nice that Craigslist was using MySQL, but it wasn’t paying our bills. A surprising number of promising web startups failed in those days.

But what emerged from that fallout, was the industry-wide recognition that if you wanted to build a high-scale company, you should use the open source LAMP stack: Linux, Apache web server, MySQL, and your choice of PHP, Perl or Python.

The LAMP stack became the dominant architecture for the next generation of developers and web companies became our fastest growing segment. Once that was under way, we knew what to measure and monitor to drive growth.

The analysis you undertake before product market fit, bears little resemblance to what’s needed once you start to scale. It can be useful to develop some basic reporting on sales and marketing performance and how different segments perform, but don’t let it get in the way of understanding the patterns that are emerging in your market.

What’s The Most Useful Reporting?

Of course, I have my own views on what can be helpful in analyzing sales performance or marketing effectiveness. Generally, it is based on understanding what is happening at the ground-level. Why are we winning or losing? What are the patterns that indicate a higher likelihood of winning? Which campaigns are bringing in the most pipeline? What is our biggest differentiator? How can we amplify that?

No one starts out by saying let’s spend three weeks building a 100 slide board deck, but if you’re not careful, that’s where you end up. So how do you keep this from happening?

First of all, be aware of the cost. Few managers are going to complain when asked to create reports for the board. But there’s a big difference between “give me what you have” and “spend 2 weeks making it perfect.” Set guidelines about what level of effort and accuracy you expect.

Secondly, when you add a new piece of reporting don’t automatically make it in perpetuity. Perhaps you only need to report on the new metric until a particular issue has been solved.

Thirdly, at least once or twice a year, prune the board deck to focus on the few metrics that are most meaningful. Too many metrics often means conflicting symptoms. Focus on the most important ones.

And finally, in lieu of creating a larger and larger board deck, consider writing a quarterly board letter as a way to provide a more comprehensive and nuanced communication for complex matters. It’ll probably take a whole lot less time than putting together endless slides. Writing out your thoughts in prose can also help refine your thinking better than the bullet point summaries used on slides.

Most boards will defer to the CEO to understand how they view the health of the company. Focusing on the basic financial statement (Income Statement, Balance Sheet, Cash Flow) and a few key metrics (Annual Recurring Revenue, Cost of Acquiring Customers, Gross Margins, Net Dollar Retention, Churn, Burn Rate, Cash Out Date) may provide most of what you need.

What’s been the most useful board reporting you’ve used? Have you tried Zeck? Slides or prose? Post your comments below!

If you’re selling B2B software, there’s a secret weapon that can accelerate your sales efforts: the SE. Solution Engineers (also known as Sales Engineers) are the key to winning the trust and confidence of enterprise buyers. The more technical the sale, the more important the SE role becomes. 

The reason is simple: many buyers have an unstated fear: what if this project fails? In today’s environment of reduced budgets and tighter scrutiny, It’s not a theoretical concern. When buyers introduce a new product or technology, they are putting their professional reputation on the line. 

So when the sales rep says, yes we can integrate with Salesforce and the deployment will take just a couple of weeks, that’s nice. It’s like the manager at the car dealership telling me the car comes with a 10 year, 100,000 mile warranty. It’s nothing I can’t read off the web site. The SE is like the mechanic who pulls you aside and tells you to record the dates of your oil changes so there’s no risk that a warranty claim will be rejected. 

SEs Win The Trust of Technical Buyers 

The more technical the buyer, the less likely they will want to engage with sales. They might be reluctant to provide detailed information about their plans, lest it be used against them in the sales process. But they still need to know whether the product will meet their needs. It’s a dilemma that is best solved with a Solution Engineer. A good SE will win the trust of the client in two ways: first they understand the product inside and out, and secondly, they understand the client’s situation. 

A good SE should be able to sit down with the customer’s team to learn more about their technical needs and integration requirements and then define a clear demo or proof-of-concept that hits all the marks and gives them the confidence of a week-long test drive. 

A great SE can take all the learnings from customer engagements and help define the product roadmap for the next six months. Not surprisingly, some of the best product managers I’ve worked with came from an SE background.

The ideal SE is a combination of a less-polished, nerdier sales rep and a junior engineer still excited by the promise of new technology, which is a good mix to win the trust of customers. They often have an infectious enthusiasm for the product which helps them connect to technical buyers. 

They have genuine curiosity about the customer and their needs. They must have strong improvisational skills when put on the spot to make something work. They might not be able to build your product, but they sure as heck know how to make it sing and work around limitations in a creative fashion. They give the best demo in the company, because rather than showing all the features, they address the specific concerns the customer has raised and put to bed any objections. And they do it while making the customer feel smart about their choice.

One Of Your First Ten Hires Should Be An SE 

SEs are great early hires because they can bridge between the engineering world where the product is built and the real world where products are deployed. They can keep deals progressing by being more hands-on than founders and early sales people. This is a powerful combination for an early stage startup, especially when you are still working toward product market fit. A good SE also knows when to bring in Product Management or Engineering to accelerate a deal. 

As you grow, the ratio of Sales Rep to SE ratio can vary anywhere from 1:1 to 1:5, depending on the complexity of the product and the level of technical engagement required. For highly technical products (or complicated customer situations) a low ratio of 1:2 may be required. For less technical products, you may have one SE for multiple sales reps. But watch out that SEs aren’t getting burnt out running customer demos and POCs from dawn to dusk. 

Takes the time to learn from your early SEs about what’s working with customer deployments and what’s not. SEs might not know they need to report back on product limitations, so make sure you create a culture where input from the field is not only appreciated, it’s actively sought by Engineering and Product Management. At Duo Security, I routinely met with SEs like Patrick Garity and Bryan O’Neil because they would give me ground truth about what was resonating with customers, what wasn’t and how our product needed to evolve.

How to Find Great SEs

The best SEs are experts in your product. I have had good luck finding SEs from within the user community and from the technical support organization. That said, not everyone who is an expert in a product is comfortable being in sales. At Zendesk we found that the more ambitious and extroverted customer support agents made great SEs. They were doing the same kind of work, but doing it pre-sales, rather than post-sales gave their career (and compensation) a boost.

While I don’t recommend hiring from customers, once in a while, an engineer from a customer might approach you. That happened to us at Gatsby, when Chris LaRocque fell in love with our product and architecture. Chris had never worked in Sales before, but his technical acumen and intellectual curiosity made him a natural. 

Our top sales rep, Luke Bivens put it succinctly: developers like talking to other developers. Luke described Chris’s contribution to the sales process: 

1. He was an engineer at heart and had firsthand experience implementing our solution in his previous role. So he knew the struggles the customer was dealing with.

2. He went above and beyond, “jamming” with engineers to make sure they achieved their goals throughout the sales process.

3. He wasn’t focused on selling—he was there to support.

Give Your SEs A Seat At The Table

Treat your SEs well. They are invaluable when selling technical products to Enterprise customers. They can provide great insights for overcoming technical objections and increase the likelihood that customers will be successful. They are great evangelists for your product and can help identify expansion opportunities within client organizations. And finally, they are often better at seeing repeat patterns among customers than sales reps, who are often so focused on their current deals, that they may not see the forest through the trees. 

Make sure SEs have a seat at the table when you’re planning the product roadmap. They're often closer to the action and have a better understanding of how the product is deployed than the engineers who built it.  

What’s been your experience in hiring and using SEs? Let me know by posting a comment below.

Thanks to Luke Bivens for giving me a kick in the pants to finish my stalled first draft. And thanks to the great SEs I have worked with over many years, including the legendary Lance Devin and Jim Cyb who are not only in the SE hall of fame, they used their experience as a foundation to build epic careers.

I spoke at the Business of Software conference in Raleigh last week and discovered three recent books worth reading. Unlike a lot of Bay Area conferences, BoS is not about lofty topics such as Crypto / Web3 / AI making the world a better place. It’s a pragmatic conference helping people run software companies, many of which are self-funded and outside the venture-backed echo chamber. As conference organizer Mark Littlewood says, attendees aren’t looking for inspiration, they want practical tips they can put into place immediately. And they got that in spades.

All three of the books hit on a central theme that came up at the conference which was on the importance of focus and alignment to drive growth. In my own work, I’ve seen firsthand how much impact you can achieve by prioritizing on a small set of important goals and then say no to as many lower priority tasks as possible.

Unlike a lot of business books that have one good idea padded out over 250 pages, you can get through these books in a weekend or over one one long flight.

Meanwhile, I’m still working on how to turn all of the essays here at Build To Scale into a cohesive book, while turning out new content at a regular, if slower pace. (If you have ideas, let me know!)

Matt Lerner - Growth Levers

Matt Lerner did a great presentation at BoS and explained the genesis of his book from his work at PayPal and as an advisor to many startups. Although his book started out as a somewhat random collection of stories, he narrowed the focus to identify the most important levers for growth.

The key to Lerner’s thinking is to really understand the patterns of behind the different customer journeys that are happening. Don’t let data analytics smooth out the outliers and leave you wallowing in averages that mask customer behavior. All of this is important in understanding which activities are going to drive growth.

Georgiana Laudi & Claire Suellentrop - Forget The Funnel

Fellow Montrealer Georgiana Laudi gave a tremendous presentation at BoS that was somewhat counter-intuitive. The “forget the funnel” concept is attention grabbing, but what she’s really talking about is that the funnel is an internal construct. You can get busy with a lot of marketing activities to chase buyers, but if you don’t understand what they’re trying to accomplish you’re wasting time and money. You need to understand their journey. Traditional funnel metrics can obscure what is really happening among distinct segments. This really resonated with me. One of the first things I do when I work with a company is to try to understand the underlying customer patterns.

Rob Nicolletti - How Revenue Happens

Rob Nicolleti has developed both a framework for focusing executive teams and a software dashboard called Halo (meaning Holistic Approach, Leveraged Outcome) for managing and monitoring progress. When he showed me the dashboard it was like a Vulcan mind-meld. I’ve never seen software map as directly to how I operate. His book was released just last week and is on sale at Amazon for the ridiculous price of $0.99. I can’t imagine a higher return on investment to founders than putting in place some of Rob’s ideas.

Check out all three books and let me know what you think. Feel free to post a comment below about any other books you have found useful in building your business.