A jaded UXer’s review of pragmatic marketing training
3 ideas that I loved 👍, and 2 that I didn’t 🤦♀️
Last week I had the privilege of taking Pragmatic Institute’s 3 Day certification training: Foundations, Focus, and Build. Your girl is now Pragmatic Management Certified — (PMC-III). 🙌
Overall it was a very positive experience for me, and I feel fortunate to work for a company that is willing to invest this much $ in professional development — Pragmatic Institute is not cheap. (Fun fact, I went through a copy-cat pragmatic marketing training a few years ago, and let me tell you it was not as good.)
I wanted to share my perspective on the training because I suspect I have a somewhat unique one compared to most people who take the course. Like most people my age I have spent 80% of my waking life up to this point in school accumulating debt and forgetting how to think critically (just kidding, kind of). I am currently enrolled in an HCI masters program where I am learning the latest best practices of user-centered research and design, but not so much the in-the-weeds business side of software. At work, I spend plenty of time in a room full of MBAs, but I myself still couldn’t tell you the difference between profit and revenue.
All that to say, that for me this course was more or less product management 101, which I didn’t realize how much I needed. However as a designer and an academic, it is my duty to be skeptical, and skeptical I am. Here goes it.
Note: I will be injecting a dose of millennialism into Pragmatic Marketing by formatting this into a clickbate-esque listicle, rating everything with an erratic emoji scale 👍👍👍👍👍, and also referring to the Pragmatic Institute books by page number as if they were bible verses (ex: Foundations 127) because these are the types of things that I find FUNNY OK?
Disclaimers Blah Blah Blah:
- The following opinions are my own, and do not represent the company I work for.
- No one has asked me to write this — certainly not the Pragmatic Institute (please don’t sue me).
- I have created visuals that communicate the same ideas as graphics used in the Pragmatic Institute slides (*cough cough* but prettier) to avoid using photos of their slides — I’m pretty sure they don’t want their slides online.
1. “Your opinion, although interesting, is irrelevant”
(Foundations, 45)
Synopsis:
- You should be making decisions based on market data, not your own opinion, and also not second-hand anecdotes like “my aunt is a [insert user persona here] and she says [something totally useful I’m sure].”
- The noisy 20% is louder than the quiet 80% (of clients, stakeholders, salespeople, etc), so work hard to get data from the quiet 80%.
Emoji Rating: 👍👍👍👍👍
One thing I have to say about Pragmatic Institute (PI) is they do an A+ job of coming up with catchy slogans to promote doing market research. This one is basically the product management equivalent of “you are not the user.”
#1 and #2 on this list basically make up one section of the training, so I’m going to jump straight into #2.
2. “NIHITO” (Nothing Interesting Happens in the Office)
(Foundations, 51)
Synopsis:
- “You won’t learn anything about market problems while sitting at your desk” [so go talk to clients, you lazy f***er]. 👍
- The market is split into three groups: customers (ours and competitors), evaluators (are shopping currently), and untapped potentials (everyone else). 👍
- You can discover market problems through two methods: observation, and interviews. 🤔
- Conduct win/loss analysis interviews with recent evaluators ASAP after a buying decision is made. 👍
Emoji Rating: 👍👍
The shallowness of that third bullet point is probably my biggest problem with this framework, so buckle up. I’ll start out by saying that I’m pleased the curriculum differentiates between interviewing and observing at all. I honestly got the impression during this section that the curriculum was designed for companies that are currently doing 0 research and need to go from 0 to like 40. We on the other hand, want to go from like 40 to 100.
My concerns:
- In this section of the curriculum (which by the way is the last whiff of user-centered research we get) there is no differentiation between users and buyers. So I’m left to speculate that either 1. they are the same person (unlikely, as this course is clearly skewed towards B2B companies), 2. it means both, or 3. we are only focused on buyers at this point, and that we don’t start thinking about end-users until the “Build” curriculum (which, you know, is about building)… yikes.
- The approach to observation described is basically a watered-down version of contextual inquiry, but it skips the important element of the master-apprentice model, in which the researcher asks “why” questions as they watch.
- The approach to interviews described is very solution-oriented one that would be much more useful for evaluating an existing product than it would be for finding the right problem to solve.
- There was NO coverage of how to synthesize and interpret data from these research activities.
My hopefully incorrect takeaway from this whole section is “Ask people what they want, and they will tell you.” It would be great if that were true, but then we’d probably have no need for UX. But is asking people what they want better than doing no research at all? I think so.
3. Strategy Matrix
(Focus, 13)
Synopsis:
- Pick a strategy, stick to it.
- Evaluate new projects based on how they align with your strategy.
- Four good strategies: Innovation, Product Leadership, Niche, Multiple Intersections.
- If you don’t pick one, you might end with “peanut butter” — spread thin.
Emoji Rating: 👍👍👍👍👍
While as a UX Designer I don’t expect to being making portfolio strategy decisions anytime soon, I think it’s important for every role to understand the corporate strategy of their company on some level. I think this is useful diagram for every designer to utilize when summing up a prospective job because the corporate strategy dictates what kind of designers the company will be hiring, and what they will be doing — researching problems, identifying new solutions, designing features for existing solutions, or twiddling your thumbs and designing slides for marketing in between redesigning the UI every 3–5 years.
That fourth line might have been how designers at Blackberry felt in 2011 when an employee wrote this letter, a great example of what happens when you get stuck in the “safe” zones of same customer same product.
4. 3-variable testing for “is this a problem worth solving?”
(Foundations, 74)
Synopsis:
When a problem is worth solving:
- It is urgent
- It is pervasive
- People are willing to pay to solve it
Emoji Rating: 👍👍👍👍👍 Game changer
Is this problem worth solving?
I mentally went over my never-ending higher education career, trying to remember if I’d ever been asked this question, and I honestly don’t think I have! I’ve always been told “UX is about solving the right problem,” but my mental model of how one decides what problem to solve basically revolves around how painful the problem is (urgency). I honestly think my own personal UX-designer-hero-complex needed to be shattered by the whole “willing to pay” thing. No margin, no mission.
This little framework is an excellent tool for a designer to have in their back pocket, and I think keeping these three things in mind is something that can set one apart from other designers.
5. “Defining the Lines” between product, design, development, etc.
(Build, 27)
Emoji Rating: 🤦♀️
This slide showed up about halfway through the build section, which I was actually really enjoying up until this point. This section focused on how to support collaboration and effective communicate with engineers, project managers, and other members of agile teams.
One takeaway I really liked was the concept of “enlightening” engineers with market knowledge to empower them to make decisions, as opposed to handing over extremely specific requirements. I believe this idea is geared towards B2B companies that don’t have designers (and therefore design decisions are made by Product Managers, Product Owners, and Engineers). However I believe it is still relevant in companies that have a more progressive designer to developer ratio. Writing requirements is a bit like (one of my favorite games) explaining how to make a peanut butter and jelly sandwich to an alien. Wouldn’t it be easier if the alien already knew what peanut butter was?
I think my point here is that successful companies foster collaboration by removing barriers between roles, being transparent with their strategy and market data, and giving people access to the information that they need to look beyond their day-to-day role. This leads to the part of this section that really rubbed me the wrong way…
You see that little box there labeled “design” squished between “problem” and “build?” Yeah, ouch. At this point during the training I looked over at the other three product designers sitting next to me, and they had all drawn all over the diagram. So had I. One of my colleagues had written “we do all three.” Another had written different design roles/activities across the spectrum: “UX research,” “UX design,” “UI design,” “UI development,” etc.
Just going to leave these things here in case any Pragmatic Institute trainers are reading this:
I think the Pragmatic Institute needs to do a little research and update their training to:
- Acknowledge the various types of design roles within an organization.
- Expand the Focus curriculum to describe specific user research techniques in detail, and differentiate between user research and market research methods. (I think both the IDEO Toolkit and Neilson Norman Group Blog are a great place to start!)
- Cover (very) basic design principles. (I think the Stanford Design Thinking framework is a great place to start!)
- Hire me to redesign their slides (just checking to see if you are still paying attention.)
Thanks for reading!
If you have taken a Pragmatic Marketing course, or are a designer trying to find your place in an organization full of product managers and engineers, I would love to hear about your experience! I also love to be told I’m wrong.
