Not every organization has the luxury of full-time product managers, team members who live in both the technical and business worlds. Whether it’s because of organizational structure or cutbacks, someday you’ll probably find yourself serving as the surrogate parent to a product heading toward rollout.
Surrogate product management means you have to balance business and software development. You may find yourself in the center of a cross-functional team and rubbing elbows with customers.
For some lifelong developers, it’s not easy to step away from the code level of a software development project. You’ll need a set of checks and balances to keep your two worlds from colliding. Here’s some advice that I’ve found invaluable for juggling these two very different sets of responsibilities.
Prioritize what needs to be done
A product manager defines and prioritizes what needs to be done on a development project. But the absence of a formal product manager shouldn’t translate into a coding free-for-all.
You must maintain control over the direction, timeline, and major milestones of the development project. While shooting from the hip is a natural reaction, sticking to a plan with milestones will help preserve the sanity of the team and the release of a viable product.
"="">Keep a customer version of your specifications
Writing specifications requires a team member or members to step back from the project and think about how features are going to work to meet customer requirements. Various team resources can be tapped to write specifications. If you have access to technical writing resources, a senior technical writer should be able to make a first pass at specs with input from you and other team members.
If you don’t have access to a technical writer and have to crank out the technical specifications, you may want to keep a light version that you share with nontechnical customers. You can easily overwhelm a customer with technical jargon. A light version of the technical requirement satisfies the customer’s need to know, but is not something from which programmers can code.
Reviewing requirements is crucial because you can run the risk of developing in a vacuum, which can create a whole host of other problems. Requirement reviews with appropriate stakeholders are necessary. Without a product manager, you may be tempted to skip the business requirements document. However, the requirements document takes on even more importance in surrogate product management because it alleviates the steady stream of nonteam members coming to your desk to check on product status. It can also serve as a tool to allocate and monitor resources for those executives who keep peeping over your shoulder.
Look for help in building relationships
Surrogate product management means dealing with other departments in the company on a more regular basis than you’re probably used to. If diplomacy and people skills aren't your strong suit, look to somebody on the team to handle the first line of internal customer inquiries and cross-departmental dealings.
For example, let’s say the technical writer on a development team is tasked with developing the requirements for a product that’s being developed under surrogate product management. The writer in turn works directly with the development lead and programmers. The writer can serve as first point of contact for internal customers because he or she is already familiar with the project’s requirements.
Somebody on the team has to act as a liaison for internal customers and other company employees, and the best candidates are team members such as project managers and technical writers who typically work in cross-functional roles.
In the case of external vendors and partners, technical leadership needs to back up marketing, business development, and executives who routinely deal with these entities.
A tricky balancing act
Protecting the technical and business vision of the product raises many challenges, ranging from more direct customer contact to writing business requirements documents. Stay on course by keeping the stakeholders involved, but not overwhelmed.