Jan 13, 2010 0
Suppose we arrange the world’s software along an axis. On the one end of the axis is the ultimate shrink-wrapped product; sitting on the shelf, waiting to be picked up by a user who will rip it open, install and use it happily, never knowing (or caring) who built it or how it was built. On the other end is the definitive tailor-made solution; written from scratch to suit the needs of an individual user, commissioned to a master developer of the user’s choosing who must have spent many hours with the user to learn of his pain and design a unique custom-made solution.
It is this axis that yields the renowned divide between product companies and professional services companies. Product companies sell software, and they sell the same software product to as many clients as they can. Professional services companies sell their time and expertise developing or customizing software for specific clients, one project at a time.
Having started my career in product companies I grew accustomed to the many advantages that a product environment provides for software developers. In a product environment you can always bring an exciting technological idea to the table, a discussion of potential markets for the new idea will follow and if it makes business sense you get to build it. Product companies take technological risks and innovate; the rewards associated with bringing a new technology to a broad market justify the risk. If you are ever asked to build something that does not make sense to you (and we developers always know best…), you can put your negotiation skills to the test in a discussion with product management. With a reasonable product manager, you can impact product direction quite nicely.
In a professional services environment, a new business idea usually starts with a new project for a specific client. The project managers rule the roost, and each project is expected to be profitable or it is not worth undertaking. Much care is taken in gathering and refining requirements and design, but this process is centered around the client, not around technology. The entire project is funded by the client and sometimes the client owns the work-product completely. Naturally it is the client that impacts requirements the most, not the developer, not even the project manager. In a professional services environment developers have much less of a say, or at least so I thought.
If all had gone according to plan I would have spent my entire career working for product companies, but then there’s this pesky little thing called “opportunity” that always seems to get in plan’s way. When I made my opportunity-driven move to professional services I wasn’t sure what to expect. What I found surprised me, and eventually helped me become a better product developer than I ever was. The first thing I learned was that professional services companies are not as bad as I thought they were. They learned a long time ago that their profitability soars with repeatable projects. They don’t really take it one project at a time. If a process or a tool can be developed to serve multiple projects they dive right in and build it, in essence developing their own mini-products. The next thing I learned was quite annoying at first. It turns out that clients who fund a custom development effort are not inclined to keep paying for the promise of a product in the making. Instead, they want tangible deliverables for their continued support. Those tangible deliverables are artifacts that we are all know and love: requirement and design documents, project plans, test plans, and other such paperwork.
I was never opposed to reasonable documentation. In fact, I can rightfully be accused of having been a bit too fanatic about internal and external documentation of code, but I couldn’t help but feel that creating the level of documentation clients required was a waste of time. We have a perfectly good design that the developers understand very well, why spend more time polishing it so that some bureaucrat can read it and stamp an invoice? We test thoroughly and efficiently, why publish an executed test plan? We already know that the product is tested. These artifacts do not help us build the product, and they do not help the end-user use it, they are simply irrelevant. I was exhibiting a bias common in the product world: The product is important, anything outside the bounds of the shrink-wrap (or the tarball for that matter) is not important. Despite this minor annoyance, life in professional services was fun and rewarding and some three years later I returned to the warm embrace of a small product company.
Guess what? I’ve come to appreciate those annoying little artifacts. You see, even in a product environment you probably have important stakeholders outside the development team, prime examples are: non-technical founders, sales teams and marketing people. These stakeholders might not sign your invoices, but it is in your best interest to keep them engaged. Just a bit of effort to gather high-level requirements and design and turn it into a human-readable document will go a long way in sharing your vision of a future product or feature. Throw together an executed test plan or other evidence of testing and their confidence in your latest release will skyrocket. My foray into professional services turned out to be a rounding experience. I learned a thing or two about engaging non-technical stakeholders and lost some old biases.
Which environment do you prefer: product or services? What do you do to engage your non-technical stakeholders? Leave a comment.
Related Link: Giff Constable, When it comes to startups, products and services don’t mix