Managing Many Voices Involved with Product Development

By Aileen Wu

Success product development requires not only blood, sweat and tears, but also a dialogue among colleagues from several different disciplines. For example, sales people, crucial for bringing revenue in the door, live in a unique incentives system of quotas and commissions, but use a variety of work styles to meet their targets. Designers, who invent the look and feel of products, are sometimes fundamentally motivated to push the envelope of convention. Engineers, who build the products and test their integrity, can sometimes be skeptical of the motives and value that business people bring to the table. When each discipline is ruled by such different incentives and philosophies, how do you manage all of these disparate voices to create a unified product?

Throughout Launching Tech Ventures, we have come across several tools useful for managing product decisions among multiple parties who sometimes each speak a different language.
                                                         
Defining Priorities through Gaming Elements – When OPower grew to 40 people, it needed to employ new systems to formalize its product management processes. One change it brought on was the “token system,” which helped the sales team prioritizes new feature requests. Sales people can be excellent resources to discover what customers want, but have a natural drive to make many feature promises to customers in order to close more sales. These requests result in a great deal of pressure on the engineering team and may distract from core product development. Through the token system, the sales team would submit new feature requests to product managers, as they did before. Then, engineers would scope out the time and resources required to build the feature. Finally, the sales people, who were allotted a certain number of tokens, would put down tokens on any given feature  to indicate exactly how important they think the feature is; the more tokens that used, the more likely the feature would be pushed forward to development. The token system was a clever way of managing the sales people, by requiring them to prioritize their feature requests with a device that was easy for the engineering team to interpret.

UPromise, co-founded by Jeff Bussgang (@bussgang), utilized the “slotting system” to prioritize features in product development. This system centered on a fun analogy – each week, the product team had to decide “who,” or what features, got to ride on the bus. The bus had a defined size or number of seats, each feature had a certain size (the engineers were tasked with sizing each feature) and one new bus came and left each week. The features that failed to make it on one week were pushed back to the following week to be re-assessed. The bus provided a structure that enabled many different parties to discuss its top product priorities of the week and, therefore, focus the company’s resources on the most critical things that had to be done.

Product Manager as a Third Party – The product manager (PM) can play a key role in mediating disputes around product development. Often, the PM is responsible for the development of a product or feature, but often has no formal authority over the others involved, such as the engineers, designers and sales people. This person helps define the specifications of the product as well as manages the execution of development over time. By setting development priorities, creating a timeline and helping clarify communication between different disciplines, a product manager can be effective in managing interdisciplinary collaboration.

Common Language Around the CustomerTapjoy’s VP of Engineering, Sean Lindsay (@rseanlindsay), spoke to our class about how to develop a good working relationship between businesses- and engineering-focused employees. One device, important at Tapjoy, is to focus product development discussions around the customer. When you make it a first priority to ask, “What would be best for the customer?” you take away the tension of whether sales or engineering “wins” any particular argument. The customer can be brought to life by using tools such as personas, which summarize the values and characteristics of your prototypical customers (meet Mary, the working mother who shops at Whole Foods…), who you want to develop your product around. In addition, user stories, which highlight the various needs that your customers run into, are important in evaluating how impactful any product change would be to your customer base.

At the end of the day, many different disciplines are needed to successfully create and release a product at a startup. The devices, listed above, may be helpful in fostering communication and agreement between different parties. However, the devices are all useless unless the various parties have mutual respect for one another, as mentioned by Sean Lindsay during his Launching Tech Ventures talk.  One way to cultivate mutual respect is to create a positive company culture as well as informal (connecting over lunch or at company social events) and formal opportunities (talks educating others about the work of any one discipline) for employees to gain an understanding of what the other disciplines do. Without mutual respect and understanding, the effectiveness and efficiency of product development will be greatly limited.


Comments

Popular posts from this blog

TCS IT Wiz 2013 Bhubaneswar Prelims

What Can be Done About Technical Debt?

Don’t code: 5 steps to an outsourced MVP