Here at VMware AirWatch, we work hard to create a progressive culture that promotes cross-functional collaboration and fosters a strong drive to execute effectively. Last year, Tony Keuh saw an opportunity for our engineering, user experience (UX) and marketing teams to work even more efficiently together—and meet our customers’ highest priority needs—when he joined VMware End-User Computing as head of product management for productivity apps. His goal: To develop a common framework and set of terminology to get teams on the same page and maximize their overall effectiveness.
[Watch: Tony Keuh on Good Apps vs. Great Apps]
Tony proposed partnering with Pragmatic Marketing to get everyone speaking the same language. Over three days, the training would cover the product development process—from customer problem discovery and roadmap development to business plan creation, personas, requirements through to markeing and more. Leadership gave Tony the green light to launch the program, which included over 50 employees across multiple discilines.
As a lead on the UX team, I was invited to attend and help support a broader implementation of the program across the company. Having worked for various product organizations throughout my career, I know how critical it is for product management, engineering and UX to speak the same language and share an understanding of how to garner and priotize customer needs. Pragmatic Marketing drove these points home, and clearly illustrated how to apply the Pragmatic approach to serve as a framework across VMware.
To give you some perspective on how teams can work together to build great technology, I asked Paul Young, VP of Products at Pragmatic Marketing, to share some of his methods and best practices. In the first installment of this two-part series, Paul shares the core components of the Pragmatic Marketing Framework™, plus approaches you can implement to help product, UX and development teams identify and optimize collaborative efforts.
“I’d describe the core idea behind Pragmatic Marketing simply as: Understand your market.”
—Paul Young, Vice President of Products, Pragmatic Marketing
You spoke about several methods and mindsets that resonated with me as a UX professional. To give some context, how would you describe Pragmatic Marketing?
I’d describe the core idea behind Pragmatic Marketing simply as: Understand your market. Everything we do reinforces this philosophy.
We believe too many companies don’t follow this simple idea. As a result, they build products that don’t resonate in the market. We deliver on that idea with training that eschews the theoretical and focuses on practical techniques that product teams can immediately implement to become market-driven.
Can you share a bit about your background and role at Pragmatic Marketing?
Prior to Pragmatic Marketing, I spent about 20 years in product management and marketing. I actually started my career as a software developer, but quickly learned that wasn’t my calling. Luckily, a role in product management opened up. My mentor gave me a shot, and I loved the independence and working across different areas of the business. Eventually, the company was acquired by Cisco Systems, where I stayed until I was recruited to build a product team at an Austin startup. After working in the startup world, I joined Dell as they first started to explore Software-as-a-Service (SaaS) and managed the product team in charge of that portfolio.
After some time, I was ready for a career change. Pragmatic Marketing had an opening for an instructor, and I jumped at the chance. For six years, I traveled to every corner of the world, from Sydney to London to San Francisco, to lead our classes. About a year ago, I joined the Pragmatic Marketing executive team as VP of Products. In addition to occasionally teaching, I manage our product portfolio, plot our roadmap, work with my peers to execute research on our market and manage our team of executive instructors.
In our training, you simplified the roles by explaining the product team collects and quantifies the problem, and design and development solve the problem. In my experience, the UX role often bridges into problem identification, as well as problem solution. Can you speak to your thoughts on the roles and how product, UX and development work together best?
Great question. Sure, the lines can be blurry between product, design and development. In some companies, there is only one person—a founder—who does market research, requirements (probably in their head), design and maybe even development.
As companies grow, the roles are separate and specialized. We see product managers tasked with market research, requirements and acceptance criteria. We see UX or customer experience (CX) designers think about efficient workflows and solving user problems in the best way, and we see developers building it in code or hardware. Whether you do these with one person or 10, whoever is doing these roles should be: a) trained to do them and b) have the bandwidth to execute.
We use the analogy of building a house. There are many roles involved in building a house: the homeowner (the product manager), the builder (development), the architect (UX and systems architecture or IT) and the trades (DevOps).
- When a homeowner wants to build a custom home, their first stop is typically an architect (UX). But the homeowner’s conversation with the architect isn’t typically prescriptive. They don’t say, “I want a 2,500-square-foot, split-level home. I’ll see you in nine months to see how you did.” Yet, many product managers write prescriptive requirements and are surprised when they don’t get what they want. Instead, the architect drives the conversation by trying to understand the homeowner’s lifestyle and problems: “Do you entertain? How many kids do you have? Do you like to cook? Are you an indoor or outdoor person?” Eventually, the architect progresses to sketches (analogous to lo-fi UX prototypes) and, if those sketches work for the homeowner, a scaled-down model of cardboard (hi-fi prototype). At some point, the homeowner says, “Yes, that’s the home I want to live in!”
- At this point, we’re nowhere near done. The architect now needs to work with the builder (development). When the architect communicates with the builder, they don’t use the sketches and cardboard models (or they shouldn’t). They need blueprints (analogous to specifications). When the builder and trades read the blueprints, they don’t ask, “Would I like to live in this house? Is it a good idea to build this house?” Instead, they ask, “If we’re going to build this house, what is the fastest, most cost-efficient way to do it?” Yet, how many product and UX teams get dragged into conversations with development about the placement of a button or justifying the business case to build something? As in building a house, there is a reason for separation of roles.
- When the builder finishes building, the homeowner doesn’t just move in and start to use the product. It needs an inspection. But that inspection isn’t done by the builder. It’s done by an outside inspector (QA) whose whole job is quality. If you draw a Venn diagram of product management and UX, there would be a good deal of overlap, and that’s healthy. We need both roles.
Here’s the way I explain it to executives. The primary role of product management is to answer the question, “Of all the problems out there, are we solving the right one?” Meanwhile, UX answers the question, “Of the problems we’ve chosen to solve, are we solving it in the best way?”
[Read: Inside the Mind of a UX Designer]
Another key point I feel is crucial to successful teams is the concept of “Enlightened Teams vs. Agile Teams vs. Development Factories,” which succinctly explains many of the problems organizations face today. What are enlightened teams, and what steps should a company take to evolve development orgs from development factories to enlightened teams?
An enlightened team knows their market. They typically exhibit more seniority, less turnover and more market exposure. They’ve also built products for this market before. A development factory is usually more junior, has more turnover and doesn’t know as much about their market or has never built products for this market before. Sometimes a team is a mix of both.
You can be successful with either model of development team, but the key takeaway is that enlightened teams tend to ask better questions. Development factories need all the details spelled out for them, which means really detailed, or maybe even prescriptive, requirements.
It’s possible to raise a team from development factory to enlightened team, with effort. We focus on this in our training, so I won’t give it all away, but we can involve them in market visits, we can share detailed personas with them, we can teach them how to ask good questions and we can give them requirements that focus on the problem—and not the solution—in order to force a conversation.
[Read: Mobile App Consistency by Design]
What benefits will the company see from having enlightened teams?
In my experience, enlightened teams tend to feel more ownership of the solution, because they were involved in crafting it. When we give the team a hard problem to chew on, and they come up with an amazing solution, they take pride in that, and it shows in their work.
Read More in Part 2
I’d like to thank Paul for his time and valuable insights. I hope the first in this two-part series provides you with helpful takeaways to incopropate into your future development efforts.
Don’t miss our next installment, which highlights the benefits of enlightened teams, the value of complete requirements and helpful decision-making tips. For more information on how to build and market products that people want to buy, visit pragmaticmarketing.com.
