the jobs/wozniak principle: understanding the division of labor in tech startups

When you're both the business person and a technical founder, there comes a moment where roles need clarification.

I'm what you might call a "technical non-technical"—someone who can build enough to sell, but not enough to scale. I can create working prototypes and demos beyond what the average business person can build, but I'm not a full-stack developer.

This hybrid skill set has led me to an interesting question: where do people like me fit when it's time to bring in a true technical partner? As I continue to build my technical abilities, I've been thinking about how roles should be divided in early-stage startups.

The answer came to me while thinking about the archetypal partnership between Steve Jobs and Steve Wozniak.

Wozniak's role was clear: he was the technical genius who could build anything. But what exactly did Jobs do?

This question gets to the heart of how complementary skills work in a startup. And I realized it comes down to a simple division centered around questions.

After all, I've come to understand that business, startups, and entrepreneurship are just a constant series of solving problems that get in your goal. And the best way to solve problems is to ask better questions.

Questions drive businesses forward. The better the framing of the question/problem, the better the answer/solution.

So it makes perfect sense to frame the two archetypal startup roles around the classic Who, What, When, Where, Why, and How (WWWWH) framework.

WWWWH framework

The business person (Jobs archetype) answers:

• why are we building this? ("we need to make computers accessible to everyone")

• what should we build? ("a computer with a graphical interface that's intuitive")

• who are we building it for? ("creative professionals and educators, not just engineers")

• when should we prioritize this feature? ("we need the mouse functionality before the presentation software")

• where should we position in the market? ("as the premium alternative to IBM")

The technical person (Wozniak archetype) answers:

• how do we build this? ("we'll use this chip architecture, this programming language, this development approach")

In practice, these questions play out in critical decisions that shape the entire trajectory of a startup.

When the business person decides WHO the target user is, it affects everything from feature prioritization to marketing. If you're building for enterprise vs. consumers, the entire product approach changes.

When they determine WHAT to build, they're making calls about which features matter most. Should we build a robust analytics dashboard first, or focus on the onboarding experience?

The WHEN question drives roadmap decisions: Should we launch with this minimal feature set now, or wait until we have the complete vision built?

It's fascinating that just one question—the how—can consume an entire role (CTO), sometimes commanding more respect than all the other questions combined.

But those other questions are equally crucial.

“build, demo, sell” vs. “demo, sell, build”

If you only know how to build something without knowing who it's for, when it matters, or why it exists, you're building blindly.

This explains why many technical founders struggle after building something impressive—they answered the "how" brilliantly but neglected the other questions.

Many technical founders follow the common fallacy of the Build → Demo → Sell cycle. Where they invest significant time and resources into building products that nobody wants or that can't evolve into an actual business. This is why the technical founder who builds something and then tries to sell it often fails.

Yes, there are exceptions like Facebook that got lucky with timing and execution, but for most people, you need both perspectives to succeed.

The business-minded founder approaches the problem differently.

They specialize in answering the WWWW questions, which naturally positions them (hopefully) to follow a Demo → Sell → Build cycle instead.

This approach determines what people actually want before significant resources are invested.

The business person (at least a good one) becomes the voice of the customer, connecting market needs to business decisions—ensuring the "how" work (the work done by the CTO) doesn't go in vain.

But similarly, without somebody who can answer the "how" question (CTO), you just have a bunch of customers who are waiting for a product that doesn't exist. (Theranos???)

Anyhow, I digressed, this whole demo sell build vs. build demo sell is a thought on it’s own which deserves it’s own essay but the point I’m trying to make here is that answering all questions is important. The difficulty in startups/biz is you got to get them all right.

final thought

The key insight is recognizing that even if you can do both (build and sell), clarifying which questions you're responsible for answering in any organizational structure creates clarity.

For someone like me who can prototype at the 60% level but also sell, the natural position for me would likely be on the business/product side—articulating the vision, requirements, and the user's needs—while partnering with technical talents who can take that last 40% to completion.

This division of cognitive labor, when done right, creates the foundation for building something truly exceptional.