Are You Building An Expertise Driven Startup?

I have been wrestling with this concept of the expertise driven company for a while now. I welcome any feedback on the model, I believe that it’s an elaboration of the hypothesis set around customer discovery and validation with a small amount of what’s involved in the early stages of founding team formation.

The concept of the “expertise driven company”  led me first to write about “The Limits of I’ll Know it When I See it”  which was an effort to draw the boundaries in a “Mechanical Turk” model for what tasks should be automated and what should be done by people. The target application was semiconductor chip design but I think the opportunities are much broader.

I then reworked it into a presentation (video and deck available at “Video and Slides From Limits of  I’ll Know It When I See It at SFBay-ACM“) but briefly I think that there three stages that an entrepreneur needs to go through to build an expertise driven startup:

1. Deliberate practice at an individual level to codify your knowledge about the problem you are trying to solve
2. Externalizing this so that at least one other person can help you critique and improve, as well as adopt and practice your problem solving techniques
3. Create a team of complementary experts who are able to address different aspects of the problem with synergy.

Each of these has a common failure mode:

1. Too many software entrepreneurs can focus on building a solution at the expense of getting  a rich map of the problem they plan to solve. And getting good at solving the problem “by hand” to some extent.
2. Unable to find at least one partner. Michael Schrage defined two pre-conditions for creative collaboration in a 2001 interview with Reveries magazine:
   

   “Successful collaboration requires a shared space. It can be shared virtual space — it can be shared physical space — but collaboration requires a shared space. But something else is even more important than the shared space.  […] look at successful collaborations — Watson & Crick, Hewlett & Packard, the Wright Brothers. Look at what these successful collaborators have in common. They faced big problems, used a shared space and had a willingness to subordinate their egos to the problem. And that is so important — there must be a recognition that you can’t innovate completely on your own, a recognition that you need to draw upon the resources and skills of other people.”

   Find at least one other person who is also motivated to understand and solve the same problem. And make sure that the problem is important enough to be worthy of both of your efforts and hard enough that you make much more progress collaborating than working alone. Find co-founder(s) who can be more than an extra pair of hands for your insights, who are able to contribute their own expertise and perspectives that will mean that together you move faster towards better solutions.

3. Not understanding all of the pieces of the puzzle that will need to be solved to build a full product–and a company to support it–and recruit talented folks who can address each piece. . If you build a team you are more likely to have the requisite variety of perspectives needed to change direction successfully when you hit a dead end. In particular it’s difficult to be good at both the technical aspects and the sales/marketing/business development aspects of a startup (at least at the same time). A small team is often more effective at managing the multiple foci that are necessary to persevere (much less succeed) than an individual or even a duo.

Finally it’s not enough to be able to offer a root cause diagnosis for a problem.  It’s much less useful, especially when the solution is a exercise left for the prospect.  I give the example of the expertise that a good physician has in my talk:

1. Elicit Symptoms (May Include Tests)
2. Offer a Diagnosis (Root Cause Analysis)
3. Explain Differentials (Sensitivity Analysis)
4. Suggest a Prescription (Course of Action)
5. Outline Prognosis (Likely Outcomes)
6. Use Outcomes to Refine Rules & Models (Deliberate Practice / Process Improvement)

I mention this because a lot of folks think that they have solved a problem when they can offer a root cause analysis or suggest a course of action (offer a prescription). It’s as important to be able to predict likely outcomes (prognosis) from your prescribed course of action and to be able to explain differentials, or why it isn’t another cause that a different expert may suggest.

My intent was to clarify key hypotheses an expertise-driven software company needs to manage and to outline  some models for collaboration that go beyond the task relevant maturity model of “tell-sell-delegate-participate” to include co-discovery and co-creation.