Posted by 
Product development projects have a lot at stake. Over the course of your project, you will face technological, resource and financial challenges. How you navigate your team through these detours will make or break your venture.
What can you do to increase your odds of success? What safeguards can you set up in your organization to flip the odds in your favor?
Having been through this process quite a few times, I can tell you that proper checks and balances will help you handle most of the upcoming issues you will face. Full disclosure: Those of you who are regular readers of my blog know that product development is my favorite phase of the venture lifecycle. With that in mind, I would like to share the following best practices with you.
Let’s begin with the big picture.
Product Development – 3 Interdependent Enterprises
Typically, a product development organization is comprised of three major and distinct functions for organizational purposes. These three areas are Development, Program Management & Quality Assurance/Test. There may be more than three groups on your product development, but in an effort to keep this discussion focused, I’m going to stick with the three areas mentioned above. They comprise the bulk of the responsibilities and tasks performed by the product development team.
The key to managing these three groups within the product organization is to outline what each IS responsible for and spell-out what each IS NOT responsible for. You’ll want to identify where each is dependent upon the others for success. This is important because you want to identify milestones and dependencies. Break the project down into components and identify which team is responsible for each step so that the project manager can keep things on track and stay on top of the overall project. Additionally, you want to make sure that you don’t have confusion regarding “who is doing what” on the team. Small ventures cannot afford to have a duplication of effort.
One of the best analogies for this process is a three-legged stool. No two legs can independently support the top of the stool and anything on it, and no one leg is more important than the other two. To succeed all three must work together to achieve the same objective. Working together, they can support massive amounts of weight on top of that stool. Now let’s explore each of the phases.
1. The Development Phase – Creating a Product or Service
Many technology-centric companies take the perspective that Development is the most important and should lead the entire product development effort. In truth, I wouldn’t be surprised if you said you had worked at an organization that was run that way. Unfortunately, this is a big mistake!
A development organization’s core responsibility should be focused on the actual “down in the trenches” work of determining which technologies should be utilized and implemented to bring this product to market. Their singular focus should be designing, coding, or building the product as per the definition provided to them by program/product management. They are ultimately responsible for all aspects of the final state of the product.
Your customer’s only experience will be with the product so it is imperative that their needs be met or exceeded and development is NOT responsible for defining what your customers want in the product. In addition, they are NOT responsible for their product once it ships in terms of GTM sales and marketing strategy or customer support.
Development’s responsibility is to develop the product as per the requirements outlined by program management, utilizing and implementing technologies they feel are the most appropriate and advantageous for the venture. The resulting product will be a on a mutually agreed upon time table with the other two groups.
2. Engaging Program Management – They Define it and Manage the Schedule
High technology companies tend to pick program management leadership to head product development if they don’t pick someone in development to do this. This can be a rational choice because program management then is responsible for the specs of the product, the timetable for delivery and will drive the project to its completion. Program management is the project lead and the source of the latest status on the project.
However, as a venture leader it is important for you are mindful of the fact that organizations in which Program Management leads the product development effort can become overly process oriented, detrimentally focused on schedules and lose sight of executing the code and technology properly with a focus on the customer experience or what the market needs.
Program managers should be responsible for incorporating customer feedback either from the sales and marketing team or directly from the customers themselves. A product specification document articulates the features and functions to the level of depth and degree necessary so that a developer can use the document as a “blue print” for their code development process. Finally, program management is responsible for managing the overall schedule for the product development process to ensure that the product goes out the door on a mutually agreed upon time-frame.
Program management is NOT responsible for determining what technologies go into the product or which are used to develop it. They are NOT responsible for micro-managing the development team or its priorities, as it goes about its activities. In my experience, program managers who have good, friendly relationships with developers are the most successful. But PMs should not attempt to manage the developers; this will most likely create unwanted and unneeded organizational friction and ill will. As a venture leader, you will want to watch for this potential hazard and intervene to keep the PM and the development team on track.
3. Quality Assurance – Make Sure It Works!
In some organizations, and in many more than it should, QA/Test is viewed negatively, as a “lesser” function and it is even regarded as the “whipping dog” of the product development organization. When QA/Test doesn’t get the attention and respect it deserves, or an equal seat at the product development table, you set your venture up for failure. Here’s why. You do not want your customers discovering flaws and failure points AFTER they receive the FINAL product in their hands! Trust me. You only have one chance to make a good first impression.
The Test leg of the stool is equally important to the other two legs and, needs to be treated as such. Their core function, as the name implies, is to test the product against QA metrics and standards to ensure that it will meet with the highest levels of customer satisfaction and approval. They are the final Voice Of the Customer (VOC) in the product development process. In fact, Test is your last and sometimes only line of defense to ensure that the product developed meets the customer’s specifications and requirements as established at the onset of the product development life-cycle. If the “code is the spec”, then Test is your litmus test to ensure the code is up to your spec.
Test is also responsible for providing final approval for the code in a product that will be shipped to customers. This enables Test to effectively serve as a check and balance for the other two legs of the product development stool. Test is NOT chartered with defining what the customers need or want, nor are they focused on what technologies are used to code the product. Sometimes Test can fall into the trap of getting too deep into the code and failing to be the VOC as they are intended to be, this can cause a lower quality product and friction in the organization.
These three organizations work in a check and balance model. Development is responsible for determining the technology and coding the product, ensuring against Program Management and Test inadvertently pushing for scope creep features and functions based on technology or customer demand. Program management drives the specifications and schedules providing a check against development and Test to ensure that the product comes out on time and on spec. Test is responsible for ensuring the quality of the product and giving final approval of go-live to ship the product, thereby providing a check against Program Management and Development pushing out a lower quality products to meet a project or customer deadline.
Overall management of the entire product development organization should lie in an individual that has all three of these organizations reporting in to him or her. Ideally this individual would have experience in all three or at least two out of three of these functions, as it will give them a better perspective on how to run the show overall. If the manager is only familiar with one aspect, they can inadvertently skew the process to that leg of the stool. It is the same as the stool having a top to which all three legs are attached, rather than having one of the three legs serve as the base connecting them together, which would make for a very unstable product development stool indeed!
If you have any questions, please drop me a note. I’d be happy to provide you with advice and guidance. Please read and share all my blogs at LeadingVentures.com.
About this blog – The goal of this blog is to share my experiences, to capture and reveal valuable insights, and to draw from my serial entrepreneur-ship through 7 ventures over the past 20 years. I have encountered many impressive entrepreneurs along the way and I hope to share our collective experience with you to help teach and perhaps motivate you to launch your own B2B or B2C enterprise.
© Jitin Agarwal – All rights reserved. This blog is property of Jitin Agarwal and leadingventures.com. Unauthorized use and/or duplication of this material without express and written permission from this site’s author and/or owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to Jitin Agarwal and leadingventures.com with appropriate and specific direction to the original content. For this blog, in instances where other previously copyrighted content, trademarks or brand references are used and noted as such, the author disavows any ownership claim, trademark, copyright or intellectual property ownership of these items and they remain the property of their respective and original owners, their inclusion in this blog is merely for illustrative example purposes only.