In the first of our two-part interview with Paul Young, VP of Products at Pragmatic Marketing, we discussed the fundamentals of the Pragmatic Marketing Framework™ and some cross-functional challenges that product development and user experience (UX) teams face when it comes to building great products. In this next installment, we ask Paul to expand on the keys to building successful ranking models, problem-solving techniques and useful decision-making tips.
[Read: Building Great Products Starts with Building a Great Team, Part 1]
“The bottom line when reading any requirement is: Can we understand what problem the requirement is asking the team to solve, and for whom?”
—Paul Young, Vice President of Products, Pragmatic Marketing
One highlight from training was the recommendation to induce empathy for the persona when writing requirements by explaining the pain and frustration the current solution causes the customer. Speaking of requirements, how can teams ensure they have complete requirements?
The bottom line when reading any requirement is: Can we understand what problem the requirement is asking the team to solve, and for whom? We have some specific formatting recommendations that we teach, but the key element is the problem, how often that problem occurs in the life or job of the user, and some color for the team to understand the context around how that problem arises for the user.
“Our key to build a good ranking model is not to look at the noisy one-off requests, but rather at the number of requests in their totality.”
Another theme throughout training that stood out was developing ways of ranking problems and requirements to keep decisions as objective as possible. What do you see as the pitfalls of allowing subjectivity to go unchecked? What are some of the keys to building successful ranking models?
This is a tough question, so I want to address something upfront: There is no such thing as a perfect prioritization method. Because all prioritization methods are designed by humans, and we’re by our nature subjective, that will be expressed in any model. That said, to the extent that we can bring more hard data to the system, the better for everyone.
When we subjectively rank, using the eye test, executive whim, what department A or B wants to build, or what the loud customer who keeps calling support or sales is screaming about, it leads to bruised feelings from whoever lost and starts to break down the team dynamic. When the team starts to degrade, they stop trusting that the prioritization will produce a winning product, then the work degrades and a sub-par product results.
[Read: Breathing New Life into UX Research]
Our key to building a good ranking model is not to look at the noisy one-off requests, but rather at the number of requests in their totality. We also take into account how severe a problem is for the user and combine those two elements together. If a problem in the market is severe, and we’ve received thousands of requests to solve it, chances are it will rise to the top.
Visit pragmaticmarketing.com to register for courses, request private training sessions and learn about other resources available to help your team build and market products that people want to buy.
What are the biggest challenges you hear about when working through the design/development phase of a project?
There are many, but here are a few that I hear often:
- Lack of resourcing in UX: In many companies, UX is a shared and highly leveraged resource. Many product teams complain that they’d like to use more UX, but are forced into doing UX work themselves because their UX team is stretched too thin.
- Lack of time for good design: In agile development, timeframes get compressed. If we’re executing two-week sprints, many teams feel pressure to ship on a date and clean it up later, but the problem is that later never comes for most of them.
- Lack of trust: The product, UX and development teams need to have a high degree of trust and collaboration. If they don’t, they won’t communicate well and the product suffers.
What opportunities do teams have to avoid these challenges early on?
Overcoming these challenges relates to soft skills such as collaboration, communication, presentation and negotiation. Of the three roles—product, design and development—none has direct power over the other. Rarely does one manage the others. I often tell the product managers and marketers in my classes that their title isn’t product dictator. A good executive team will work to foster effective relationships between these teams.
[Read: Mobile App Consistency by Design]
How have you seen UX teams work successfully with product management and development? What traits/habits did these teams exhibit that you feel made them successful?
Because UX and product teams have similar goals, the front-end of their work in terms of research looks very similar. I love to see UX and product teams pairing up for field research. In addition, UX and product teams should have regular touch points where they share their research, what new trends they’ve found and how that will impact the product.
What are the biggest misconceptions people have about creating great technology products?
I think one of the biggest misconceptions people have is that magical founders come up with a killer idea and conquer the world. We have a hero worshiping culture, so it makes for a compelling story that Steve Jobs did this, or Bill Gates did that.
They were undeniably titans of their industries—but they also did a ton of market research. Apple in particular did, and still does, lots of research on products and features. It’s not just blind luck or a clairvoyant hero.
“… companies that are doing well have figured out how to integrate good design with good problem identification and good engineering. The bar for what the market considers to be a good product goes up every year, so we have to raise our game, as well.”
While many companies have figured out the right way to design products, other companies still struggle. Why is that?
My theory is that design as a distinct role is still fairly new, and companies that are doing well have figured out how to integrate good design with good problem identification and good engineering. The bar for what the market considers to be a good product goes up every year, so we have to raise our game, as well.
In companies that aren’t doing this well, the design team is marginalized and under-resourced, or the product team doesn’t exist, and products are built based on great ideas and loud customers. You can be successful that way, but it’s risky and not a path to long-term success.
“With every new feature add and every new release, everyone on the team needs to be able to clearly state, ‘What problem are we solving today?’ If we can’t answer that question for a given feature, it shouldn’t be in the product.”
Are there any insights you can provide for enterprise teams in particular?
It’s harder for enterprise teams to meet their market because the numbers are smaller, so it can be useful to set up what I call a “traffic cop” role. This is someone who manages everyone’s contact with the limited user base so we don’t run over the same people again and again.
In addition, enterprise products tend to cover big problem sets, so the importance of usability increases immensely. With every new feature add and every new release, everyone on the team needs to be able to clearly state, “What problem are we solving today?” If we can’t answer that question for a given feature, it shouldn’t be in the product.
What is one thing most companies aren’t doing but should to build great products?
Go to Pragmatic Marketing training. Just kidding. Here’s a list:
- Make regular contact with your market, and not just the ones calling you.
- Test and re-test your ideas with that market.
- Prototype extensively.
- Separate design sprints from build sprints.
- Use data to drive prioritization.
I’d like to thank Paul Young for his time and valuable insights. The activities he lists above are absolutely critical to building successful products. While these sound simple when you put it in a bulleted format, executing these important functions can often present challenges when put into practice. My conversation with Paul was refreshing and certainly enlightening. I hope it provided you with some helpful takeaways to incorporate into your future development efforts, too.
For more information on how to build and market products that people want to buy, visit pragmaticmarketing.com.
