The 10 Thorniest Problems In Product (And The Solutions That Successful Companies Are Using To Tackle Them)
As research for my upcoming fourth book, I’ve been interviewing dozens of product leaders and creators. Combined with what we learned from writing Product Leadership the patterns are becoming increasingly obvious: Product teams around the world are all encountering the same handful of problems.
Request: Obviously every company or product team will have context-specific factors that make their situation a little different. Instead of yelling at the screen telling me why these solutions won’t work at your company, please share your unique experiences and help us all get smarter. Thank you!
1. How do product teams that are spread across geographies, time-zones and functional areas of work find alignment?
The biggest challenge facing remote or distributed teams is not some unmet technology solution. It’s not a better conference calling solution or another task management app (no more project management tools, please!). The real challenge is getting to know each other. Specifically, it’s the lack of opportunities to get to know each other that hurts teams.
Strong bonds of trust are harder to form when teams are not co-located. If I don’t get to know you, then it’s harder for me to trust you. Knowing you gives me confidence in our ability to understand each other. Seen from the perspective of the company, trust and confidence, almost always lead to alignment. Head of Design and User Experience at Philips Lighting, José Manuel dos Santos, sees creating alignment as his primary job.
José believes that “Every company engages in an effort of trying to understand how to align a strategic direction with everyday work.” He describes this alignment as nothing more than making sure that “The different people in the organization, which all have different perspectives, different ways of working, and different ways of engaging the future, all just want an opportunity to do their job.”
Frequent meetings explicitly for the purpose of discussing the vision, values and purpose are essential to healthy team relationships. In successful organizations, conversations about vision and values are not confined to the annual company meeting. These product orgs find ways to inject these conversations about alignment into their daily informal conversations, ongoing mentoring relationships and highly visible communications.
2. How do product teams balance weak signals and anecdotal evidence with contradicting quantitative market trends?
At user-centric product companies like Pluralsight, it’s often the case that when faced with these conflicts “the customer breaks the tie”. This is a very reasonable way to weight market-based (externally sourced) quantitative evidence against product specific qualitative feedback from your own user studies. Breaking the tie with qualitative feedback (e.g. user interviews) works if the conflict is with market data. This is because each product potentially has a unique value proposition and won’t always be aligned with the macro market or industry data.
It becomes much harder to evaluate these things when the external sourced data is at the product level because the differences between competitive product features are almost indistinguishable to the end user. Furthermore, at the product level, the customer’s behavior is often driven by brand loyalty or emotional investments in that product.
Ultimately the research needs to demonstrate unequivocally what the customer cares about most. If you’re unable to isolate the problem the user wants solved, and connect that problem to a solution you can provide, then all the market data in the world isn’t going to help.
3. How do you balance building on known usage patterns with inventing new (or improved) ways for customers to use an interface?
This could probably be answered in a similar way to the above qualitative vs quantitative argument — what does your customer care about? If new patterns make a big difference to how your customer perceives your value then you should invest in those patterns. If the switching costs are high, or users simply don’t care enough about the incremental changes, then adding “new and improved” features or patterns will be pointless.
Ultimately, it’s a very context specific question. Knowing how to balance trending best practices with the observed patterns which align with your user’s perceptions of favorable user experience is essential. In highly technical environments a challenging interface may actually serve the user’s needs for validation as an expert, while in broad reaching consumer UI this could create the reverse outcome.
For example, GE Renewable Energy’s product team develops digital tools for highly skilled engineers to evaluate wind turbine effectiveness. Interviews with these users reinforced that these users value their technical education, skills and experience, and overly simplified UI in apps and digital tools can feel “simplistic” and “condescending” to these users.
4. How does a team strike that delicate balance between sticking to the vision and adapting to a changing world?
A good product vision is timeless and, whenever possible, should be separate from the underlying technology. It should be able to stand the test of time and be as relevant today as it was yesterday.
In general, a company needs a mission more than a vision. But their individual products will benefit from each having a product vision. A good example is the Tesla mission: to accelerate the world’s transition to sustainable energy. There’s not anything in this mission about electric cars or solar panels, it’s a broad rallying cry for the business and context for the products that live inside the organization.
I share the opinion of my partner at Heroic, Geordie Kaytes, when he says, “A company doesn’t need a vision to survive, but it’s going to be rudderless without a clear vision for each of it’s products.” A company, or the organization that owns the product, really just needs a problem worth solving to keep it focused and aligned with why it should exist.
Without a clear product vision, which is a description of a future outcome not yet realized, the product organization will be hard pressed to align their capabilities and resources.
5. How are products organizations adopting new technologies like AI, ML, and IoT?
Technology is great when it amplifies our human powers and makes us feel super-human. A startup in NYC, CrisisTextLine, is using machine learning to help crisis counselors. “Our tech scans incoming text messages to identify what the underlying problems are. It then suggests valuable insights to counselors to improve resolution or care” explains Sarah Bernard, who recently joined CrisisTextLine from Jet.com, where she lead product.
Technology for technology sake is harder to align with business needs because initially it’s mostly a curiosity and has lower sustainable value. Understanding the value of the technology for your customer means understanding the problem they are trying to solve. As Garrett Kroll says, “It’s much more than creating, it’s about understanding your problem so well that the solution is obvious.”
Most companies I speak to are not ready for these new technologies. CEO, of Nara Logics, Jana Eggers reminds us, “You might be capturing a lot of data but if it’s not labeled you’re not going to go very far with machine learning or any kind of analytics. Companies need to be running basic experiments to test their capacity for using AI.” Data capture and distribution is still at the fundamental stage for many. The solution for most seems to be to create low-risk experiments that allow product teams to test new tech with select users.
6. What should product teams do when they miss deadlines and don’t ship on schedule?
If your team is getting close to an ideal cadence, then you’re almost always shipping something. Maybe you’re making small daily fixes and improvements, or maybe it’s a bigger monthly release, but you‘ll be shipping very regularly. Missing deadlines in this modern context is more about discovering that your estimates were optimistic.
The skill to be learned here is accurate estimating. “Your product should have an ongoing stream of value and new features/capabilities and fixes and updates and cool stuff that your users want” says Rich Mironov. “Even when things seem to be on schedule, good product managers will be secretly planning for possible delays or interruptions.”
Instead of beating themselves up for missing a release date, product teams should be asking, “why are we estimating poorly?” or “why is our planning consistently off?” Slipping on deadlines is a downstream problem. Figure out what’s going on upstream and apply that learning to the next release.
Another consideration is how you communicate the release schedule. PM’s need to be cautious about letting marketing or sales dictate the deadlines. For teams that are on a continuous release schedule, marketing and sales should only be supporting new features once they’ve been validated in the wild by test users or small scale releases. For highly public companies like Apple, Tesla and SpaceX, it’s hard to say if the age of the big reveal will be replaced be continuous releases. The reality is most of us aren’t launching sports cars into space on massive rockets.
7. How should product teams regroup after failure?
Closely related to the above, any failure is a portal to new knowledge. It’s unexpected research. It’s not the ideal way to do research, but it is valuable feedback nevertheless. The experience of failure, not only formal research, can bring forth the insight.
“The first rule of failure is to talk about failure.” Says Perry Hewitt. Because failure feels personal, people tend to clam up or want to move on without acknowledging it. “They don’t know what on earth to say, so they avoid discussing it entirely. Make it your mission to address the elephant in the room, by acknowledging the failure and looking to understand underlying causes.”
As with everything, failure is contextual. If a company has been created with the explicit reason to support a product then product needs to come first in every major decision. Put another way, if your company exists because of the product, then product failure often puts the entire company at risk. If your company is just a holding structure for multiple products then the overall portfolio needs to be accounted for. In these cases a company may choose to let a product fail so that the overall structure can support the other interests in that portfolio.
What’s more important than organizational structure is team character. Deanna Brown Aho, previously head of product at Cengage Learning, says this of the product people who are the most resilient to failure, “People who can laugh a lot, have a sense of humor, move forward, not take it all too seriously, but love their craft are going to push forward. If you take everything personally, you’re going to be crushed.”
8. How do we build a pipeline for product talent?
Schools need to stop prioritizing learning facts and start teaching soft-skills. Product companies need humans that are not just fact-sheets but are better at relating to one another, solving problems and being more creative. Machines (AI, robots, automation, etc.) will soon be doing the grunt work of data analysis, if they aren’t already. Practical, immersive programs like the one’s run at Jared Spool’s Center Centre or Melissa Perri’s Product Institute are much more useful for creating prepared talent with life skills that matter.
For students or learners not able to do full-immersion programs, we now have an embarrassment of riches at our fingertips. Online learning communities like Pluralsight builds skills based on industry needs and delivered by industry experts. Combining this community-centered model with AI that helps learners level up based on their current skill set, you have a killer model for developing talent.
I’m a little biased, but my favorite talent pipeline is the apprenticeship model. European countries have been doing this for 100’s of years. The programs that work best focus on practical, customer-facing work with mentorship from the folks that have mastered these skills. My UX design company has been running a UX apprenticeship (called AUX) for several years and we’ve seen over 50 people graduate and go onto amazing futures. We made the AUX curriculum open-source so anyone can replicate this program.
There is no one solution to talent development. A combination of the things above should be on every product leaders mind. Remember, the velocity of your team is determined by it’s slowest member. Level them up and the entire team gets a boost.
9. How should a product team divide the ‘build’ functions from the ‘run’ functions of a product?
The answer to this depends on how the product org is structured. In an ideal world the product team that is responsible for building is also responsible for running (and iterating) on the solution. This continued relationship with the product gives them a higher degree of customer interaction and thus learning opportunities.
For decades companies have organized themselves around projects. It might be easier for the finance team to plan and fund this way but it’s shortsighted. Teams need to be focused on persistent business issues (i.e., the customer problem), not trendy cycles or the current crisis. When a tech company is organized around product, as opposed to project, the result is a more nimble team that can ship experiences in true continuous fashion. Unlike a project, which is discrete, product team is supported by the org on an ongoing basis, assuming they continue to deliver value to the end user.
In recent years it’s become fashionable for ‘build’ teams to transfer ownership of the product to separate ‘run’ (devOps/designOps) teams. This misses the point of doing user-centric work. When done correctly devOps/designOps is an organizational style and culture, not a role. Divided product teams don’t gain valuable understanding via customer feedback (solution validation).
10. What should product teams be prioritizing, and why is prioritization so hard?
Okay, this is really two questions but they are tightly linked. Let’s start with the fact that prioritization, or the lack thereof, is another downstream problem. Your team can’t know what to work on next if there isn’t a clear vision, and an articulated strategy for how that vision is going to be executed. As I’ve written before, the biggest threat to getting things done, is knowing what to get done.
There is a school of thought that the Product Manager decides what to prioritize, and this might be true some of the time. But the reality is all PM’s are working backwards from a vision. If the vision and the strategies to reach that goal aren’t clear then the priorities won’t be clear either. Product leaders need to invest time crafting a clear vision and strategy for the priorities to be clear. If the vision and strategy are clear then it’s a more practical game of asking “what needs attention right now?”
Deciding what to ship and then doing whatever it takes to support that is what most PM’s aspire to. That can mean a PM has to also roll up their sleeves to ensure that priority remains a priority. As InsightSquared founder, Sam Clemens says, “If it means being in the weeds, then do it. If it means getting out of the weeds and building to go live with some customers, then do that. Whatever supports your primary job of deciding.”
The bottom line is you need both the guidance of a clear path (vision and strategy) and a strong “decider” role. The buck needs to stop somewhere. That person is very often the PM. It’s in the best interest of the product organization to support this person with data, facts, resources and access.
Prioritization is a huge topic and it’s not possible to cover all the ground here. If you want to learn more I recommend reading Product Roadmaps Relaunched by Bruce McCarthy, CTodd Lombardo, Evan Ryan and Michael Connors.
Request for feedback
What problems are you seeing in your teams or market? How have you dealt with these problems? I’d love to hear how you’re tackling these challenges.
If you’re working on a product team and would like a super useful toolkit, you can download from Radical Product, or read about how it’s used.
