Intrepreneurship vs. Entrepreneurship
I attended a lunchtime panel by the Northern California chapter of the Product Development Management Association (PDMA) last Wednesday. Very high quality event—I can’t say that about all of them, but this one had good panelists, good questions, and good food (most important thing!).
One question came up about how rigorous we need to be regarding product management for new product development. In particular, the question concerned the difference between a startup environment and a large company environment.
Someone made the point that rigor is more important in a large company because there are more constituents involved. In a startup you usually just have a handful of people and a limited set of customers; there is less coordination required.
A panelist made the counter point that when you’re developing a new product, you’re almost always working in a small team; even in a large company, what the new product initiative boils down to is a small, entrepreneurial team within the corporation. That sounds about right to me, but I disagree with the next thing he said.
He said that since big companies are rigorous about requirements gathering and other product management functions AND big company new product development actually happens in a small team, therefore startup teams should take product management rigor as seriously as in a big company.
It seemed logical to me at first, but then I got to thinking about it. There seems to be a big difference in the degree of newness you have to deal with in a startup. A new product initiative in a big company is most likely going to be an improvement on something the company already does. You’re not starting with a blank sheet of paper in a big company the way you are in a startup. (If it were a blank sheet, the big co probably wouldn’t support it and someone would leave the company to do it as a startup.)
From what I’ve seen, in a big company, a new product initiative has to be integrated with an existing product, or it addresses a big new requirement from an existing customer base. Generally it is attempting to extend the technology or broaden the solution for the customer base. I think the need for rigorous requirements gathering stems from this. If you’re going to extend something, you have to define what you’re extending and explain how what you’re building interfaces to it. If you’re broadening the solution for the customer base, you have to go out and survey as many of the existing customers as possible, talk to your sales people, etc. All that interaction means you need documentation.
I think it’s different in a startup, at least in the case of a Disruptive Innovation where there is little definition to your market. Maybe you can’t even tell who all the customers are. There may not be any competitors and therefore no generally accepted features that must be in a product of your category. There might not even be a category yet. It’s a blank piece of paper.
That’s why what we’ve been using at my startup company is a single piece of blank paper to track requirements. It’s based on an idea David Bayless of Evergreen IP shared with me, the 8.5” x 11” Prototype. We write down all the ideas we think matter and we shop it around. As we shop it around to our customers and potential customers, we make some things more important, we make some things less important. We add new ideas. We (sometimes) cross out ideas.
Then we give it to our developers who tell us what’s feasible to do in a given period of time. They’re a great team that’s been there, done that. They know how to fit the features together, improvise and solicit feedback when appropriate. I think the level of skill you have at your disposal in a startup is another factor that makes rigorous requirements gathering and PM functions less important in a startup team than in a big-co new product development team.
I saw this again the other day when I interviewed an engineer at Oracle who came in through a startup acquisition. The candidate was ready to quit because Oracle was suddenly slapping all kinds of process & control on the acquired team. The candidate wanted to get back into a startup situation where developers have more responsibility for the requirements gathering, interpretation, design, implementation, and validation. I guess they felt the big company processes stifled the creativity in a startup.
I’m no expert on this stuff, but it just seems this way from what I’ve seen. What do you think?
One question came up about how rigorous we need to be regarding product management for new product development. In particular, the question concerned the difference between a startup environment and a large company environment.
Someone made the point that rigor is more important in a large company because there are more constituents involved. In a startup you usually just have a handful of people and a limited set of customers; there is less coordination required.
A panelist made the counter point that when you’re developing a new product, you’re almost always working in a small team; even in a large company, what the new product initiative boils down to is a small, entrepreneurial team within the corporation. That sounds about right to me, but I disagree with the next thing he said.
He said that since big companies are rigorous about requirements gathering and other product management functions AND big company new product development actually happens in a small team, therefore startup teams should take product management rigor as seriously as in a big company.
It seemed logical to me at first, but then I got to thinking about it. There seems to be a big difference in the degree of newness you have to deal with in a startup. A new product initiative in a big company is most likely going to be an improvement on something the company already does. You’re not starting with a blank sheet of paper in a big company the way you are in a startup. (If it were a blank sheet, the big co probably wouldn’t support it and someone would leave the company to do it as a startup.)
From what I’ve seen, in a big company, a new product initiative has to be integrated with an existing product, or it addresses a big new requirement from an existing customer base. Generally it is attempting to extend the technology or broaden the solution for the customer base. I think the need for rigorous requirements gathering stems from this. If you’re going to extend something, you have to define what you’re extending and explain how what you’re building interfaces to it. If you’re broadening the solution for the customer base, you have to go out and survey as many of the existing customers as possible, talk to your sales people, etc. All that interaction means you need documentation.
I think it’s different in a startup, at least in the case of a Disruptive Innovation where there is little definition to your market. Maybe you can’t even tell who all the customers are. There may not be any competitors and therefore no generally accepted features that must be in a product of your category. There might not even be a category yet. It’s a blank piece of paper.
That’s why what we’ve been using at my startup company is a single piece of blank paper to track requirements. It’s based on an idea David Bayless of Evergreen IP shared with me, the 8.5” x 11” Prototype. We write down all the ideas we think matter and we shop it around. As we shop it around to our customers and potential customers, we make some things more important, we make some things less important. We add new ideas. We (sometimes) cross out ideas.
Then we give it to our developers who tell us what’s feasible to do in a given period of time. They’re a great team that’s been there, done that. They know how to fit the features together, improvise and solicit feedback when appropriate. I think the level of skill you have at your disposal in a startup is another factor that makes rigorous requirements gathering and PM functions less important in a startup team than in a big-co new product development team.
I saw this again the other day when I interviewed an engineer at Oracle who came in through a startup acquisition. The candidate was ready to quit because Oracle was suddenly slapping all kinds of process & control on the acquired team. The candidate wanted to get back into a startup situation where developers have more responsibility for the requirements gathering, interpretation, design, implementation, and validation. I guess they felt the big company processes stifled the creativity in a startup.
I’m no expert on this stuff, but it just seems this way from what I’ve seen. What do you think?
posted by Michael Osofsky at
9:11 PM
4 Comments
