Throughout the life cycle of a product there will be ups and downs. Times when the hype is high, and times when the path forward is uncertain. These waves put pressure on the Product Manager to constantly lead, no matter the situation. What if you’re not sure that the company is moving in the right direction? Or you’re not confident in the performance of an upcoming release?
If you feel this, you’re likely not alone, but as the leader of the product, you must project optimism in order to keep your team with you.
Whether you like it or not, people are looking at you. They pick up on your expressions, your reactions, and your attitude. When you are bearish on a decision, that attitude has a way of permeating through the product team and other stakeholders. People will divest in the effort and become skeptical about the path. Projecting optimism will do just the opposite. Showing that you’re confident in a positive outcome will give the rest of your team something positive to look forward to. It will keep those around you calm in the face of uncertainty, and will give them a reason to follow you. It will even give your team confidence that a solution can be found in difficult situations.
Successful PdMs will need to lead teams and products through thick and thin. Being optimistic about your future and confident in your decisions will keep you and your team feeling positive and focused on moving forward. Next time you notice confidence weaning on your team, try projecting optimism about the situation, because if you don’t—who will?
As more software companies turn their focus on healthcare, Product Managers who are new to the industry will notice the intricacies that make building, launching, and maintaining a product in healthcare different. Healthcare is one of the most unique industries in terms of regulation, data sensitivity, and social impact, which pushes product teams to take novel approaches to typical “playbooks” that exist. While healthcare’s strict privacy rules, high costs, and siloed software systems can make it seem like an unattractive industry to work in, that is just why more of us need to help. The outcomes of improving anything from health data analysis to back office efficiencies all impact care in some way, and can ultimately improve the health of our society. That is the ultimate pay off. I hope to provide a little bit of insight into some challenges you’ll face as a PdM in healthcare, preparing you to build healthcare products for the first time.
Note: My experience is primarily in building products for hospitals in the context of registration, patient flow, and back office operations.
Secure environments and sensitive data
Hospitals take security very seriously. Everything from how the building is organized, to where their patient data is stored, to privacy agreements with patients create a complex security apparatus that makes it difficult to obtain the typical data sets about your users that you’re accustomed to. For example, you may have trouble finding a usage analytics tool/framework that works for you and your customers. In many cases, simply using Google Analytics will not be viable out-of-the-box, especially without a BAA in place with Google. Although it may be unintentional, there is a potential that some of the monitoring may pick up PHI in certain events, and even if that is cleared on your end, hospital security teams may have issues with that data going to Google. In more secure settings, hospitals may even want you to operate in an on-prem/off-net setting, eliminating your ability to use conventional tools to collect usage data in the cloud. This challenge is both a technical and communication hurdle.
Be proactive about all things security and data. Setting up environments and analysis tools in non-compliant ways will only cause more pain transitioning later and when having conversations with potential customers. When it comes to collecting usage data, consider using a hosted solution (piwik), or a home-grown solution if needed, and do it early. If you want to get metrics that are based on the PHI (Protected Health Information) that you’re collecting, this will require more secure analysis infrastructure (for instance we have a separate HIPAA compliant, AWS cloud with Zeppelin to do analysis), so plan ahead. I also cannot understate the value of in-depth security documentation describing your architecture/data collection practices. This will save you hours of phone calls with security teams and make you seem more legitimate to potential customers.
Complex and siloed health data
If you’re new to healthcare and plan to build something that leverages patient data, be prepared to spend a significant amount of time learning about the different data protocols (HL7, FHIR, etc) and terminology sets (SNOMED, LOINC, CPT, DRG, ICD, etc). These standards are in place to classify and label information, however many of these are not used in standard ways, creating issues for non-experts when trying to leverage the data. Connecting to sources of this raw data is often difficult, and each hospital will use slightly different system configurations and prefer a different connection method. For instance, some hospitals that want to leverage HL7 will have to pay upwards of $10,000 to set up an interface for your product that will allow HL7 to flow bidirectional. Also note that these are some of the challenges just to read this information. When writing back to a patient’s record, you’ll need to be even more careful managing patient data.
Besides establishing analysis environments early, its important to define your end goal for your data analysis upfront. This will help you focus on the specific data types that you really need to understand and will give you the capacity to dive deep. For instance, if you want to do analysis on different diagnoses that patients have and your data is coming via HL7, you’ll need to first learn to parse the HL7 to the correct segment, then to decipher the content in that segment (likely an ICD code for consistency). Knowing where you want to end up will guide you to work through learning these different conventions one at a time, and to not overwhelm your team with the dozens of other terminology sets at once.
Live Feedback Nurses,
doctors, and anyone working in a hospital setting for that matter, are extremely busy (not to mention, there aren’t enough of them). They are also working directly with patients or with patient data throughout the day, so it can be challenging to find a time and place to meet with a user/potential user for feedback. Product teams will have to do a little extra work to get feedback from these specialized users/customers.
As with any product, there is no substitute for getting out in the field, but with healthcare specifically, this may be the only time you get with your target users/customers. Spend as much time as you can at hospitals with customers or prospective customers, asking questions, observing, and meeting with as many departments as you can. Go on sales meetings, installations, or even exploratory conversations if you can get them. Although we all have our own experience in healthcare settings, being there for research, not as a patient, will give you a different perspective. I personally found this to be a little awkward at first, but the insights and empathy for your users that you’ll gain is invaluable. Always be cognizant of the fact that “once you’ve seen one hospital, you’ve seen one hospital;” they all operate a little differently, and you’ll gain new insights from each conversation.
Validating New Product Ideas
It’s hard to validate B2HC (Business to Healthcare) ideas with traditional B2C techniques. Hospitals are hesitant to try “just any” software they find on the internet, and it’s tough to reach the right audience with a simple landing/sign-up page to gauge interest. To make any progress, you’re going to have to get more hands-on.
First, if you have any existing customers, leverage any time with them to validate your new ideas. For everything from sales decks to demos, you existing customers will be a great starting place for validation. When presenting a new concept in a healthcare setting, whether it’s a mockup or a prototype, I recommend making it feel as real as possible. No need to lie about progress or waste too much time on working software, but presenting something that seems incomplete may limit your ability to gain traction in your conversation with a risk-averse healthcare customer. We’ve used many techniques from Ash Maurya’s “Running Lean” over the years, particularly the problem and solution interviews.
Always have the patient in mind. A fair amount of my time has been building products or features that a patient never interacts with. Our customers typically evaluate the ROI of these products by how they reduce costs in some way. In the end this eventually translates to better patient experience and outcomes. Remember that at some point, everyone is a patient. Focus on the end goal of health.
As a Product Manager, you own the decisions made about your product. This doesn’t mean that you are always actually making choices, but that you are responsible for facilitating the making of decisions and are held responsible for their outcomes. While the outcome of a decision is the typical measure of success, I believe that PdMs should also focus on how quickly they can take advantage of an opportunity. In the fast-paced landscape of technology companies, especially startups, taking weeks or even days to make a decision could be long enough to render even a “perfect” decision (probably doesn’t exist) useless. All too often, to a fault, analysis is valued over execution. In this blog, we’ll explore how to leverage action to make better Product decisions.
To illustrate how overanalysis can cause a missed opportunity, consider the following scenario. You want to improve conversion on your website as a new competitor is beginning to take some of your potential users. You think you can make-up ground by improving the usability of the sign-up flow, and want to take some time to analyze the current sign-up data, do some user groups, run a few A/B tests, and optimize your site from there. While this sounds like a fine plan, PdMs need to be cognizant of the time they’re spending on optimization and planning in comparison to the magnitude of the decision. Doing user groups and inconsequential A/B tests over a matter of months may lead to a solution capable of doubling conversion rate, but at that point your competitor may have already swayed a bulk of your potential users. Also, how valuable are those acquired users in the end anyways? If you were able to make a slightly less informed decision that resulted in a slightly worse conversion rate improvement, but in half of the time, the end result would likely be a gain in users over your competitor. PdMs need to constantly evaluate the importance and impact of decisions with the amount of time and energy required to make it.
“This reveals something counterintuitive about decision making: your goal shouldn’t be to always make the right decision, it should be to invest the right amount of time in a making a decision relative to its importance.” – Brandon Chu, Making Good Decisions as a Product Manager
To make more effective product decisions, I recommend trying out the following techniques:
Keep the end goal in mind
Sometimes it’s easy to get caught up in the details of a problem, forgetting what the actual end goal is. It’s helpful to take a moment to slow down and identify what the end goal is, which is usually larger/broader than the task at hand, and make sure you’re not getting hung up on details that will only have a minor impact. To do this, try increasing the visibility of your end goal, and tracing all changes/initiatives/tests back to that goal, so that your team always has their eye on how their work relates to the bigger picture. A good Product team will call things out if they feel out of line.
Plan to learn along the way
No decision will ever be perfect. Expecting to fail and learn (in a controlled way) along the way will put you in the mindset of execution, rather than endless analysis. This comes down to managing the expectations of your manager, team, and yourself. Knowing upfront that you’re going to take some chances makes acting on those chances earlier easier. Instead of building out a plan, which includes knowing the answers or delaying a decision, break the decision up into smaller, prioritized decisions and start at the top. Working through this list will allow you to make better smaller decisions that are less risky and daunting, allowing you to learn faster. Having this expectation at the start will take the pressure out of the situation.
Doing something (within reason) is better than doing nothing
Action typically outweighs idleness when faced with a product decision. This feeds the learning mindset, pushing you to take steps towards your goal, even if they are not 100% the right steps. The key to managing this risk is to keep the steps small, and to tackle lower-risk problems with less information while spending more time on higher-risk decisions. Those small steps will compound into leaps of positive progress, and you will have made them quickly. One of our company core values at CrossChx is “excuses are for losers”, so every time I’m faced with a decision where there doesn’t seem to be a clear path forward, I remind myself that there is always something that can be done. There is typically no excuse to do nothing—there is always something that can be learned.
Being at the center of products, PdMs own the result of all decisions made. To effectively make decisions, Product teams typically employ a number of frameworks, but can get bogged down in the perfect solution. To take full advantage of opportunities, PdMs should consider the timeliness of their decision heavily against the potential impact of their decision. Making the right decision too late isn’t valuable to you or your customer.
Afterword: While searching to see how other PdMs feel about this topic, I stumbled across Brandon Chu’s blog Making Good Decisions as a Product Manager (quoted above). I cannot agree more with his post and recommend reading his post if you want a deeper dive on the mechanics of this sort of decision making.
To me, the role of Product Management is to identify opportunities presented by users, customers, or the market, and then to capitalize on that opportunity by leveraging the collective capabilities of the company (by building software, designing a shoe, offering a service, etc). Notice that Product is merely working with other divisions to accomplish the ultimate goal of seizing opportunity. While Product Managers (PdMs) tend to be intelligent, well-rounded people, they are not experts in all areas required to make a product successful, nor should they be.
Steve Jobs famously said “It doesn’t make sense to hire smart people and then tell them what to do; we hire smart people so they can tell us what to do.” It’s typically not Product’s job to hire the entire team, but PdMs should follow the same sentiment when working across the company. The PdM won’t necessarily have direct “authority” (in terms of reporting structure) over engineers, marketers, or designers but will need to leverage all of their skill sets and input in order to make their product initiative a success. Enter the need to be able to lead without authority.
Before diving into how to effectively lead without authority, it’s worth highlighting a few day to day examples of why Product must lead without authority. At the highest level, Product may need to rally people from several teams behind an idea or opportunity. Perhaps there is an opportunity for much needed revenue or an idea for a new feature that a PdM feels strongly about, they will need to gain buy-in from people across the company, above and below them, to drive their initiative to success. Once an initiative is off and running, PdMs play a key role in motivating all parts of the team to execute and maintain a consistent cadence. While this is also a shared responsibility by those involved, the PdM should keep the team focused and engaged to move the project forward. Finally on a more micro level, PdMs help lead and facilitate smaller decisions on a daily basis. For anything from a design change to an adjustment in priorities, the PdM will need to help ensure proper due diligence is done and provide insight/direction from their point of view.
Given this context, I believe these are three of the top techniques for leading without authority:
Evangelize your vision and desired outcome
In order to lead a team to achieve your product goals, you must provide your view of the future first. I like to think of this in the form of a vision, showing how you see this particular plan playing out, and in the form of a desired outcome, providing a more tangible end goal. The former is not a prescription of how the product/initiative must look in the end, but a story about the potential of the initiative, which should energize the team to participate. The latter is more solid; it gives everyone a tangible metric or goal to work toward and gives context to why the project is important. This will become more important in point two.
As you convey your vision, try to tell a story that will resonate with your audience and that goes past the conclusion of current project. You want your team to be energized by the impact that this project will have and where it will take the company in the future.
When providing a desired outcome, I find it best to accompany it with solid reasoning and data about why it is the right thing to “chase” right now. Many times, this ties back to a company goal, tactic/strategy, or vision, and it’s important for everyone you’re working with to understand that.
Leave it to the experts
As we’ve already noted, it’s most effective to allow experts in each area to own decisions in their particular domain. That is why point one is so important. It allows the PdM to think deeply about the vision and desired outcome for a given initiative, and then leverage the collective and individual expertise of each team member to make decisions in their space. A PdM that tries to dictate solutions or approaches in others’ areas of expertise will likely make suboptimal decisions and sour relationships along the way.
To do this effectively, present your end goal to each stakeholder, and then ask a lot of questions about how they think they’ll help achieve the goal from their perspective. Try to understand what they see as critical, then help them formulate a plan to achieve that. The most important point here is to put your faith in their decision, while making sure everyone knows how all of the pieces fit together.
Celebrate the hard work
After all of the releases, campaigns, tests, cold calls, and mockups the product has achieved its desired outcome or at least you’ve learned a ton along the way. Along that journey it’s important to celebrate the team’s accomplishments but even more important to put the emphasis on those that you’ve worked with. After all, they likely did majority of the leg work and they typically aren’t the first to be recognized when others think of the product or initiative. Showing this genuine praise will help you gain trust from those on your team, and will attract others in the organization to want to work with you on future projects.
Praise can come in a lot of ways. It could be giving someone credit in a meeting with other leaders, a post in your #general Slack channel, or an explicit callout at an all company meeting. As long as it’s authentic, praising your team’s work will return dividends when you’re in the trenches together. Honorable mention for this point: get to know your colleagues on a personal level and don’t be an jerk.
While leading without authority is a less technical Product Management skill, I contend that it is the most important skill for a PdM to have. So much of the job depends on coordination across the company (which cannot be made up for with intellect or time), that it’s hard to make progress without it. Experiment around with these techniques to see what works with your leadership style; you’ll know you’re on the right track when you no longer feel like you’re fighting for control.