Six Ways Interaction Designers Should Act More Like A Product Manager
“So why should I understand what a product manager does?”
It’s because 60 to 70 percent of what Interaction Designers do has a direct correlation in skill set to the Product Management job description. Outside of pricing models and a few other business methodologies, good Interaction designers can easily act as Product Managers in many environments.
Great product management and product design is the crossroads of minimizing risk and maximizing value.
With the advent of the user experience process, it can be argued that many Interaction Designers are better trained in Product Management than the Product Managers they work with. Product Managers are trained in business theory and have to learn how to build and project manage a product; Interaction Designers are trained in the process of building a product and connecting it to engagement and business value.
It has many commonalities with great user experience — we push the boundaries of great design and technology while mitigating user adoption risk. That’s why learning how to act as almost a “second Product Manager” can be impactful: your influence can go much further than just the interactions because of how much you should know about the product development process.
It’s about showing everyone that great product design isn’t about control or dictating direction, it’s about impact and process related results. It’s about a team that where everyone can be a product owner and be part of the process. It’s about changing the dialog from management to team oriented results.
We can turn conversations from the worthless “make the button blue” threads to “what you are trying to accomplish” within context of great product development. Defining that context is the best result any Interaction Designer can deliver for their organization.
Understand the business model
Repeat after me: no service is ever free, you just aren’t paying for it.
When designing any product, the most likely goal is to make money. Some designers think user experience is some altruistic pursuit that’s funded by a magical non-profit money machine. Unless you work for a non-profit where you are trying to save the world, that’s wrong.
If you’re working for a startup with investors or a larger business that’s bringing in revenue, everything you do should lead to the almighty dollar, whether it be user acquisition, engagement, or the most direct way, a direct conversion. Designers design for goals, and what you are solving should meet the goals of the company.
Know the user journey inside and out, and figure out what you can do to get that user to convert to something tangible. Establish user goals that are directly related, and work with the product manager to make sure those goals are reflected in the product roadmap.
The last thing that an Interaction Designer should ever think is that they are the most important person in the organization.
Companies are very complex places where User Experience is but one part of the larger machine. Your wish list is prioritized with the wishes of sales (more features!), marketing (features they can talk about!), and engineering (features that don’t cause the system to crash!).
Pick your battles and ask yourself the following questions when pushing any feature:
- Is shipping more important?
- Do you really need it to be pixel perfect?
- Does every form element need inline help?
- Can you get by the minimum viable user experience?
If you take an iterative approach to design, you can learn more with smaller steps than with giant leaps. Remember that every minute you spend on a feature it’s costing the company money. If you ask developers to build it, it costs that multiplied by the number of developers on it. If it’s a feature that is half baked, you’ve wasted precious time and money.
In other words, pick your battles wisely.
Understand the organization
Interaction Designers should never end their thought process at how the user uses the application.
What User Experience designers should be doing is talking to almost everyone in the company and figure out how the complete service works, from customer service to accounting to engineering. The best opportunities are usually outside of your job description.
The best example is customer service: representatives on the front lines are some of your best allies. Ask them questions over lunch or a couple of drinks, and learn their jobs. Sooner or later, you can propose solutions that make their lives easier.
Many times, those solutions are what I call “two-fers:” you can solve two pain points at the same time.
At one job examined at the customer service process and figured out low-cost ways to improve the process by including more help text before customers asked questions. Emails dropped 25 percent over a month, and revenue went up. It the end, we had happier customers and cut overtime to zero by providing better solutions.
The best thing about the three legged stool of Product Management, User Experience and Engineering is the healthy conflict it generates.
Conflict generates passion, viewpoints, and eventually results in better solutions if handled right. You can turn that conflict into an advantage and control the conversation. Here’s how:
Have a beer with the engineers to understand their pain points. Ask them questions about implementation, and think about solutions. Have a beer with the Product Managers and ask what they are trying to get accomplished. Ask them questions, and learn their pain points.
Then you can be white knight that rides in and saves the day because you can propose the solution that meets both the goals of product (profitability and engagement) and engineering (stability and less complexity). You can facilitate and negotiate. This process builds trust not only in the UX process, but the product management process as a whole.
Product development can be the Tower of Babel, but great designers can be the Babelfish of any organization.
Every once in a while, I slip into UX Speak, which is code for using jargon thrown around at clients for processes and terms that we purposely make hard to understand. Ethnographic research? That’s studying users in their environment. User Journey? That’s that pesky user lifecycle thing. Wireframes? Personas? Use Cases? It goes on and on.
We should be speaking in the languages of the people we are working with. Engineers want to hear engineering terms. Product Managers want business terms. Everyone wants a common language to speak about the common goal.
We should define that common language for them.
Set the common thread of communication by describing the business in language everyone can understand, and evangelize that in every corner of the organization. Gently correct users during the product definition process, and you’ll be amazed how quickly context will be understood.
Great product leaders create one path that everyone can follow, and that’s as simple as defining where the path starts.
Ownership means that you care.
The biggest difference between being an Interaction Designer and a Product Manager is exactly this: Product Managers are product owners — they are where the buck stops, and are ultimately held accountable for every decision.
They are also responsible for being a leader, and getting buy in from the organization. If they can’t build support with soft skills, no amount of mandates from the CEO will save the product. Everyone from the programmers down to the customer support will ignore the product manager (I’ve seen it, and it’s ugly).
If you show ownership in your work, you’ll fight for what you think is right, and will put your job on the line if you think a way of think. It means taking chances, not playing it safe. It means making decisions that you own, right or wrong. It means taking responsibility for all calls, good and bad.
The Money Shot
Great Designers and Product Managers get people excited about creating great products without the need of a title, and should be able to explain holistically how the decisions made contribute to the long term success of the product.
That may mean making decisions that may seem counter intuitive in the short run, but if they can describe their vision, that all important buy in can be an important asset in product success. Evangelism in any field is a great skill to have, and if you can cover more than just the UX role, that makes any team an unstoppable force.