When delivering a new product or service under conditions of extreme uncertainty, you need a range of skills.
To help understand what skills are needed in a startup team, I’ve found it useful to think of people’s skills as being spread out along this line.
Consider people you know, and place them on the line. e.g. A UX designer who can also code Javascript is maybe somewhere towards the technical end of product.
1. Technical
This is someone who understands the substance the product is made of in great detail, and can work it to do what is needed. So for software, a computer geek.
2. Product
Deciding what the product should do, by both understanding what is possible with the technology, and what is needed by users. A product manager.
3. Market
Classifying who customers are, what inspires them, how to find them. Using whatever methods to help bring them to the product they want. A marketeer.
4. Sales
Filling that last gap between a product and its users. Cold calls, hustles, pesters. Whatever it takes to bridge two organizations. A salesperson.
Product/market fit boundary
Some lucky (skilful!) people sit right in the middle. They have a balance of product-side and market-side skills, and as a result often seem preternaturally good at crafting organizations.
You can train yourself to get nearer to that place – sales people can learn more product design, geeks can learn about marketing. And of course, you can join forces with people with complementary skills.
Why put all this on a line?
Two main reasons.
1. People’s skills are more likely to be near some point on the line. It’s common to find technical people with some product skills, rare for them to have full on sales skills. It’s helpful in terms of spotting balance – if your technical person is very extreme, it might help to have a product person who is over towards the market side.
2. There are analogies (homomorphisms, if you know your maths) between the roles, as if the product/market fit boundary were an Alice in Wonderland mirror.
- Hacker (doing all to make tech work) is the mirror of Hustler (doing all to make a deal work)
- Developers claim they have time to code everything, Salesmen claim they have time to sell to everyone
- Geeks tell you too much about particular tech, Salesmen tell you too much about particular deals
- Making (what product people do) in the mirror is Meaning (what marketing people do)
(I suspect these homomorphisms are quite deep, see my post on product and market being the same thing for a taste of why that might be)
I’ve found such analogies help me understand both the vital importance, and the weaknesses, of those different from me. It emphasises that to create a viable new product or service, you need all four skills working in unison.
In a world where a key limiting factor in the creation of new businesses is a lack of social ties between product-side and market-side people, it’s a start.
Also worth reading in this context is my post “Mapping the product/market space – an hallucination” http://www.flourish.org/blog/?p=734
It sheds a bit more light on what I think the different people are doing.
e.g. “Consultants and salesmen work busily all over the map, stretching tendrils out from multiple products by hand, extending filaments from the bright areas into the dark.”
A reply on the back of a napkin:
Needing a range of skills is clearly important, and I agree with the context you’re setting – strongly. However, something about the line jars me. I don’t think market and product, within the continuum make sense.
The line (possibly unintentionally?) implies that the skills increase towards the ends. That is: more skill in marketing means moving towards becoming a salesperson. The more skilled in product means moving toward coding. A very skilled marketer is not a salesperson, and skilled salespeople often make terrible marketers.
Overlaps in skills (or, perhaps overlaps in understanding?) are vital for startups. In fact, they’re starting to be seen as more vital for established firms (cf IBM teaching managers fundamentals of design). For a startup, what you’re after is a range of skills, knowledge and experience spread among fewer people than a bigger firm can get hold of, even if they do want to cross-train their managers.
Perhaps abstracting might help? Skills involving human understanding (which affect both marketing and product design) can manifest as marketers (terrible term), UX designers, product designers, analysts… ad nauseum. Technical skills involving logic and problem solving appear in engineers, developers and product owners? Skills involving hustle and quick thinking become analysts, salespeople and possibly evangelists.
Also, don’t you think that part of getting this collection of skills working together needs some of Stafford Beer’s feedback loops?
Zach – thanks for your comment!
On the tech/product side, I think geeks being aware of what makes a product, and product managers knowing what is technically possible/easy are both really important.
So I’m happy they’re “next to” each other not because the skills are the same, but because it’s important to have quite strong awareness of the adjacent skill.
I think this might be true on the marketing side too, but I’m not sure as I don’t know it as well.
I like the idea of human understanding, technical problem solving, and hustle quick thinking as a triple of skills. Maybe I should be drawing a triangle with more detailed set of roles?
Ooo! What kind of thing are you thinking for feedback, specifically across a range of roles?
I think the adjacency is part of the feedback. Structuring teams and reviews across the skills might be one incarnation (I know ScraperWiki does that, for example.)
But more than reviews, I think deeper working together can be more helpful. Paired-programming works well for producing code, but paired tasks with experts in human understanding (UX has some overlap with communication?) and design can help.
But I think that the line between product and market (and the skills being on either one or the other side) might be problematic.
If market and product are the same thing (or have some sort of correlating relationship) then the skills need to cross that line *all the time*. Someone who has problem-solving and logical skills can help to understand the market from a quantitative POV. And human-understanding skills (knowledge of language, knowledge and behaviour) can help craft the product and bring priority to the development cycle.
So: paired tasks, reviews, and teams which cross the skills are all potential wins. And adding formal studies with both quantitative and qualitative perspectives can help with market, design, and prioritising. (A piece of work being an investigation, which has both stats and behaviour). Research and direction might have a similar relationship as product/market: “a piece of research” / “development plan.”