I like to say that I’m multilingual. Not because I can speak English and French, but because I can “speak” business and tech. And I can marry the two together (Biztech? Techness?).
As a product manager, my role is to translate the business requirements of end users into a product plan that makes sense to both the business side and the tech side. I exist somewhere between the two teams since I’m not purely business and I also won’t be the person programming or developing the technology. As a product manager, my product plan needs to be technical and allow our development team to execute while also clearly communicating the business requirements.
For example, many product managers today are hearing that their customers want better analytics. But it isn’t a good idea to have your engineers dive head-first into developing an analytics solution without knowing your users’ requirements. How will the users leverage the product? How will their experience need to change for desktop vs. mobile cases? What types of security protocols are needed? What questions do they need to answer?
You don’t want your product to miss the mark, and that’s where the PM’s translation skills come in.
As a product manger, I could just make my best guess as to what the user will need. But over the years, I’ve learned the best way to perfect my translations skills is to go directly to the domain experts. I may be building healthcare tech, but I’ll never be quite as knowledgeable as a nurse who needs to analyze hospital readmission rates. I could be building an analytics app for manufacturers, but I will never understand all the job nuances of a factory floor worker on a production line.
By taking the time to talk to end users, I can at least come as close as possible to understanding the intricacies of how they do their jobs and their specific pain points. I’m able to pick up on trends that are happening and gain a better understanding of how they work and what they need. What does their day look like? When do they use this product? What information needs be available? What problems are they trying to solve?
Knowing this information means we can build a better product that is tailored to the roles and skills of the people using it. It means less training and higher adoption, because the product is intuitive and fits seamlessly into their workflows.
Of course, it’s a two-way street: Just as the business team determines new needs for the product, the technical side can also come up with new, innovative ideas. I’ve seen a few instances of development and engineering teams proposing new technical capabilities to the business side—and the business side taking those suggestions and creating new business possibilities.
My advice for product managers? Stay open to new ideas no matter where they come from. Although they know the ins and outs of end user needs and product requirements, sometimes the technical team will suggest something they hadn’t thought of which helps reach the end goal faster and in a more sustainable way. It’s all about those translation skills. By taking the time to meet with customers, and truly understand their business, our developers and engineers can deliver the best product possible.
No matter whether ideas come from business or tech, it’s all about translation skills. By taking the time to talk to both sides of the business—as well as the end users—product managers can guide the business and help developers and engineers deliver the best product possible.