One thing that we love to do at Stay SaaSy is provide very direct specifics on what we would do or how we would think about problems. With the different changes going on with AI, we thought that it was timely to put together some thoughts on how team structures and responsibilities are changing at a very tactical level. These takeaways are derived from managing teams, investing in startups, advising companies, and our own network discussions.
Experiments
It’s increasingly feasible for very small teams to fully vet expansions to your product-market fit (e.g. one PM + one engineer; one product-oriented engineer + a part-time designer + a salesperson; one technical god-emperor PM). PMF expansions are things like a product that gets you to a new buyer persona, a new market segment, or dramatically increases adoption / consumption / competitive win-rates. They are the lifeblood of a high-growth business – high-growth essentially demands a major PMF expansion at least every year or two.
Pre-AI, frequent skunkworks projects were a tell that your teams were too constrained by bureaucracy. That isn’t the case anymore because 1-2 person teams can run orders of magnitude further with AI, flipping the ROI calculation. Launch that new Payments product that Product Marketing said would never work. Translate the whole product into Mongolian and see if you can break into a new market. Launch a new set of integrations from scratch.
Tips:
- Only very competent team members should be working in this way. The teams embarking on these skunkworks expeditions must have at least one person with excellent product and business sense.
- The only way that skunkworks projects ever work is with time-boxing and clear success criteria. Literally nothing about these parameters has changed with AI; if anything, there’s now the additional parameter of a maximum token budget.
Design
Frontier models (and also, by the way, cheap as hell non-frontier models…) can design stuff that’s pretty good, and pretty good is enough for some products. If you’re a home insurance business, great UI is better, but I don’t really care how beautiful your product is – what I really care about is the price and coverage of your goddamn insurance. For better or worse, you need to accept this.
Simply put, many teams need fewer designers than before. Fewer designers means a tighter-knit vision and smoother collaboration, both of which are absolutely critical in the AI era – without a tight team of regulators it’s never been easier for user experiences to catastrophically drift.
“But soon we won’t need any UI” – first off, no. We didn’t spend a million years of evolution looking at stuff on the savannah just so that we could process the world through WisprFlow transcripts. We might need less UI, but we are still pretty far from needing 0. But second, even if most of your product is destined to shift into a remote-controlled MCP world, that is in itself a form of user experience that needs a consistent design vision.
Tips:
- This isn’t universal advice – there are some products that do require great design, and if you are in that category you still need top-notch design (and the bar is rising).
- You probably also need better designers than you had before, because they need to be able to communicate well and think much more broadly about your product and business.
- This also means that designers need to be more tuned into the needs of the business; it isn’t enough to just be able to drive great aesthetics.
- The value of an excellent product-design system has gone up, because now it’s not just giving you consistency, it’s also fencing in a barely regulated army of unsleeping, unblinking, ever-coding agents.
Product Builders
There’s an increasing number of “Product Builder” types of roles – people who span engineering and product, business and code. These people have always existed at early-stage startups, but pre-AI their wings generally got clipped as companies and codebases grew. It was simply too impractical to be able to focus on the deep work of coding while also spending significant time with customers / the market. Coding agents have bridged much of that gap because it takes less deep focus to build many features.
Here’s my philosophy on this one: there are certain people who just have that Builder Gene, and will reliably build better products than others. We can debate whether it’s innate or can be taught – in my opinion it’s innate – but it doesn’t really matter. The overall fact of the matter is that some people have it and some people don’t, and the ones who have it should just be building way more with AI since that’s now possible.
Tips:
- There are a few ways to tell who has the builder gene, but the most predictive one I’ve seen is who has good product ideas. Good builders overwhelmingly have better product ideas than others, and can come up with new ones effortlessly.
- Developer experience and guardrails around review, QA, etc. are extra important nowadays because a lot of these builders may not be trained full-time engineers.
Resource Allocation
Many companies had long-term friction between executives who wanted nimble resource allocation, and practitioners who claimed it to be difficult. There were elements of truth to both perspectives, but there used to be a lot of reasons to push back on rapid, scaled resource reallocation:
- Onboarding into new areas took a long time, so you often didn’t get the results you wanted for the effort exerted.
- Shifting expertise often created voids in subject matter expertise that were hard to fill, and especially painful when on-call forced teams to confront that reality.
Now, this equation has dramatically changed:
- Recently added teammates can quickly contribute and own new areas. Shifting people from other teams can pay off quickly.
- SME gaps are less painful as on-call gets more automated and existing teams can answer questions about the codebase more easily.
Practically, many of the best companies are being much more nimble with resourcing. Resource allocation doesn’t necessarily mean completely moving an entire team and everything that team owns. Moves such as moving people for single projects, or even entire teams for a quarter or more, are increasingly fantastic and workable tools in the impact arsenal.
B-Teams
For a long time we’ve said that creating B teams was always a failure mode. AI hasn’t really changed a lot of that dynamic – creating a lesser-than team still suffers from hiring, promoting, resourcing, and morale issues.
But what AI does catalyze is the presence of A+ teams – the elite commandos of organizations.
In a world where the best contributors were maybe 5x the average, it was more important to spread expertise than it was to combine it. However, with AI, you might have several 100x contributors, and in combination their efforts can alter the trajectory of your company as long as you remove roadblocks from their path.
Enter the A+ team. Small teams, 2-6 people including PM and Design, where there are absolutely no weak links. Everyone is a 100xer. That team can constructively multiply each other’s efforts in ways that are simply not possible if they’re being held back by (say) a merely mortal 5xer.
Tips:
- There should still not be any B-teams.
- But you’re likely making a mistake if you don’t have at least one A+ team deployed to your highest-leverage needs.