Staying afloat as a PM even when your company isn’t product driven
An early PM’s take on learning the weeds of Product Management in a highly engineering driven organization.
By Anu Ramakrishnan
It’s not uncommon for highly technical and specialized startups to evolve into becoming pseudo ‘product’ companies, without truly realizing what it means to be product driven. Product Management in itself is a relatively new definition to activities [such as defining product vision, strategy, design and execution] that may have traditionally been performed by marketing, business development or maybe even engineering. While large tech companies value product managers and empower them to, in some essence, be the CEO of their products, or at least a component of it, several other industries like healthcare and finance are yet to fully realize the value of this role. So, how does one thrive (or more realistically, stay afloat) in such an organization?
My journey into product management happened in a mid-size digital health company who’s R&D team pretty much comprised of engineers at varying levels of seniority, who did everything from defining the what, the when and the how — mostly executing continuously on what was being asked of them from cross-functional stakeholders, marketing included. While product management did exist (resting under the broad umbrella of ‘marketing & biz dev’), much of it was product marketing management with a huge focus on downstream marketing (i.e. driving sales). The aspects of focusing on innovation and determining what customers would want next was often determined by the executive team and often passed over to engineering to merely execute on, so even at a product level, there wasn’t a solid process around road-mapping and prioritization. To add another layer of complexity, my role reported into engineering as I was transitioned over from an engineering role, so I was essentially viewed as an extended engineer tasked with writing PRDs.
Despite these constraints, the aspiring PM inside of me wanted to make the most of this opportunity by learning the weeds of (real) product management, while meeting the company/team’s asks of me.
These are a few things I did to stay afloat as a PM in a highly engineering driven organization.
- Shifting the focus to the user.
One of the first things I did as a PM transitioning over from engineering is to start thinking of things in terms of the user. Identifying user personas, their journeys, pain points and challenges was fundamental to me to often answer the “why are we doing X” question. As it was challenging for me to get an opportunity to speak directly with our users on the field, I spent a lot of time (getting at least second-degree information) talking to as many stakeholders who work directly with customers instead. This included our sales team, product marketing, usability teams and even experienced engineering managers who have dealt with our user pains in some form in the past.
Another useful thing to do is to read about your user demographic — in my case, 65 year old patients, physicians, medical assistants and clinical technicians who worked over 18 hours a day. What does their typical day look like, what tools & technology do they use on a daily basis (…it’s often pen & paper), what are their motivations? This is information that doesn’t necessarily require you to be a PM to avail, but is extremely important to know to be successful as a PM. Having information about users was also helpful to back me up in pushing for a feature that was not as favored by engineering but still brought tremendous value to the user (and therefore the business).
2. Learning about the importance of design
The organization I then worked at did not have an in-house design team, and any projects requiring design efforts on web & mobile were often outsourced. However, there’s still a lot you can learn about design by sitting in on design reviews, understand visual design systems, color & typography, design constraints based on the system (for example, desktop VS mobile), the user (21 year old college student VS. 80 year old grandmom) and the context (Class II medical app VS. an online dating app). Fortunately, I worked on a range of software projects — ones that already had a defined visual design system to ones that required a brand new redesign, both of which provided me with ample learning opportunity. I was also fortunate to participate in design sprints (conducted in-house by external design contractors) which let me hone on my wireframing & prototyping skills, which are also super essential PM skills to have. I also spent time outside of working learning to use popular design tools like sketch, which definitely helped me develop design empathy!
3. Writing effective stories.
Being in a Class II/III med-device company put tremendous importance on having well documented software requirements for regulatory audits, but as a PM, there’s definitely a lot of room to take a step back and define crisp user stories & use cases which typically pave way for software & design requirements. Tying #1 and putting everything in the context of what a certain feature or software component is doing for your user(s), as well as going through use cases & flows to cover as many edge cases as you can possibly identify upfront so you can design for extreme users & constraints is extremely valuable. I found adopting the Gherkin format of writing stories & acceptance criteria particularly helpful in defining requirements in an implementation agnostic way, which is important to ensure you’re empowering your engineers & designers to own and design the detailed software implementation without doing it for them.
4. Backing strategy with data.
It’s often challenging to be a strong voice in a purely engineering or purely marketing driven organization, however, that doesn’t mean there’s no point in trying. As a PM who used to spend much of her former days doing data-analysis, I often ensured any strategic decision I pushed for (be it introducing a whole new back-end workflow to support a new user sign-up process, or tweaking with the timing & content of push-notifications), I ensured to back it up with data and insights wherever possible. (It was a pretty successful strategy, given how the key decision makers were engineers anyway!)
5. Improving domain knowledge
Another tactic to become a quick favorite amongst other non-engineering stakeholders is to develop knowledge about your product domain. Being in the med-device/digital health space, it helped a lot to understand the payer ecosystem, reimbursement challenges, competitive landscape, popular clinical trials and studies in the field and of course, compliance. This comes in handy in several places — to differentiate yourself from the core engineering folks who may have a one-sided view to product, to empathize with other stakeholders and their requirements, and to understand, question or challenge any decisions that may affect your product.
Needless to say the advice I have above applies to any PM in any field, but these were definitely the things that helped me the most given the constraints that were unique to the organization I was then a part of. Every company’s product team is organized differently (i.e. might be a standalone PM group VS. PM reporting into engineering or marketing) and has unique product & market challenges depending on the stage the product is in (i.e. new VS. mature product, growing VS emerging markets) and I personally believe that there’s never a ‘right’ or ‘wrong’ way to doing product management, as long as it makes sense for the organization and helps achieve product goals.
