Engagement metrics: When you don't know why people use your product, but want to make up a metric to measure your PMs on because you read an article about how numbers are objective
Ostensibly customers want to use your product to fill a need, then put it down. But engagement doesn't measure filling of needs. In fact, it measures the opposite - time spent using the tool, with the need going unfilled (what @jmspool calls tool time) articles.uie.com/dividing-user-…
@jmspool Setting a metric to track implicitly or explicitly drives the team to improve the metric. By selecting Engagement as a key metric, you run the risk of telling your teams "we want you to add more things to click, and delay the user reaching their goal for as long as possible."
"as a user, I want to be engaged, so that..." - said no one ever
Engagement is not always the wrong metric to track. But it should never be the only one, or the primary one, as long as you have any kind of visibility into why people are using your product in the first place.
Understanding how to measure the value your product's value for users is hard! @johncutlefish has a great guide on what that work entails.
Engagement or NPS might seem like viable alternatives to doing that thinking and that work, but they are not.
Often, the gap in the process isn't a lack of user research, but a lack of mechanisms that incorporate user research insights into product decisions. Don't take it for granted that this is something obvious for everyone.
This can be as simple as calling a meeting, putting your list of insights up next to the list of decisions, and asking "in light of this information, do these decisions still hold?"
Which is why it's crucial to have one central place where you can document those decisions.
If your stakeholders can't clearly articulate their decision points for the product or what evidence they used to make the decisions they did, it will be much harder to get them to change their mind through presenting new evidence.
"Empowered" teams are often like "agile" teams or "flat orgs" - the term is used as a feint to stand instead of the capability, rather than to signify it.
They have the same logic: an executive team who wants to mollify the workers, but doesn't want to give up their control (because they are still under the illusion that certainty is possible).
You are empowered to do anything you like, so long as it's what we tell you.
"We are design driven" = the executive team decided what they wanted the designers to do, then did a "design thinking" workshop to make themselves feel good about it
Adaptive expert: can apply skills to a wide variety of situations
Rote expert: memorized how to do a series of tasks correctly
UX, Product, and related disciplines suffer from the replacement of the former with the latter, but rote expertise isn't suited to design problems.🧵
This is especially clear with something like Scrum, where all problems are solved by applying the same patterns, regardless of whether they are suitable. But it's appealing as a worldview to novice PMs because training in Scrum ceremonies is much easier than learning how to PM.🧵
Rote expertise is what leads these PMs and designers to scorn user research. When all you have is a hammer, there's no reason to evaluate the appropriateness of using a nail. Just draw the Sacred Artifacts (persona, user journey, wireframes) and then go make a Design System.🧵
The fidelity of your design artifacts needs to match the fidelity of your research insights. Getting ahead of your knowledge with beautiful mockups that rest entirely upon assumptions is AT BEST wasted work, and at worst burns design's credibility with stakeholders.
1/🧵
Without research, the value of anything you're drawing is purely speculative. But it doesn't look like it to non-designers - without being immersed in the use case, all they see is "the design is done." They will expect to see that thing built.
2/🧵
When new evidence suggests that this design is not the right solution, it will be a struggle to convince stakeholders that changes need to be made. Even if product hasn't already started cutting tickets and scheduling work - the first design sticks firmly in people's minds.
3/🧵
Labor market: *realizing that their labor is underpaid*
VCs: Forget about that nonsense and do work for free instead, your boss will definitely appreciate it honest
You know what happens when you work weekends?
Everyone knows that you're the sap who will work weekends. That's it. You don't get ahead by doing more of the same work. You get ahead by making your impacts more visible, and good luck doing that when everyone's living their lives.
Instead of spending more time working, spend more time looking at why you need to work those extra hours, and attack the root cause. You'll cut the chaff and spend 40 hours a week on high-impact work, instead of 56 hours on nonsense other people have saddled you with.