Showing posts with label Agile. Show all posts
Showing posts with label Agile. Show all posts
Thursday, November 18, 2010
Post on Customer Development and Product Management
I've written an article for Solvate on how Product Management can benefit startups that use Customer Development. Solvate is a service that enables businesses of all sizes to find professional talent "on-demand". The article is titled "Product Management in an Agile World", and you can read it on the Solvate site.
Sunday, January 10, 2010
Buzzwords Without the Benefits
The eBook software company that I work for was just merged into a larger software division of the same company. This larger company uses Extreme Programming (XP) primarily as an excuse to put developers into pens. While other companies using XP put two developers into each cubicle or office, at this division, developers sit side-by-side at long tables with no privacy. The developers could just as easily be machine tools.
If the company was really getting benefits from the approach, I'd say that the human cost might be worth it, but they only manage to get one release out a year. Neither time-to-market nor responsiveness benefits from their approach. Developers are moved from project to project in order to meet staffing demands, so it's difficult or impossible for them to build and maintain domain expertise. There seems to be plenty of demand for customer support, so their approach isn't resulting in easier-to-use or higher-quality products.
I'd argue that the only reason that this company has been successful is that it's selling into a very conservative market that changes and adopts new technology very slowly. If they were competing in a more dynamic market, they'd have their heads handed to them.
It's easy to convince yourselves that you're experts in a given field if you're in a market cul-de-sac or technological backwater. An easy way to fall into this trap is to benchmark your operations against your direct competitors--that's what the U.S. automakers did, by comparing themselves against their next-door domestic competitors instead of the best companies around the world. The smart thing to do is to benchmark yourself against other similar, but not necessarily competing, businesses. Identify what they do right and what your direct competitors could learn to use against you.
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=f79a0170-c294-49aa-ac0b-f72cbf5d8a9b)
If the company was really getting benefits from the approach, I'd say that the human cost might be worth it, but they only manage to get one release out a year. Neither time-to-market nor responsiveness benefits from their approach. Developers are moved from project to project in order to meet staffing demands, so it's difficult or impossible for them to build and maintain domain expertise. There seems to be plenty of demand for customer support, so their approach isn't resulting in easier-to-use or higher-quality products.
I'd argue that the only reason that this company has been successful is that it's selling into a very conservative market that changes and adopts new technology very slowly. If they were competing in a more dynamic market, they'd have their heads handed to them.
It's easy to convince yourselves that you're experts in a given field if you're in a market cul-de-sac or technological backwater. An easy way to fall into this trap is to benchmark your operations against your direct competitors--that's what the U.S. automakers did, by comparing themselves against their next-door domestic competitors instead of the best companies around the world. The smart thing to do is to benchmark yourself against other similar, but not necessarily competing, businesses. Identify what they do right and what your direct competitors could learn to use against you.
Subscribe to:
Posts (Atom)