having observed "design advocacy" in many orgs, I've noticed some patterns:
1/n: the very things that get design the "seat at the table" become the limiters for further advocacy. So much effort to create a box ... and then you forever get put in it
2/n: @ryanrumsey talks about this eloquently, but you often see a complete resistance to making a cogent "business case" for why people should care.
Part of this is pride -- which is understandable -- but it becomes "design advocacy" vs. "design as a catalyst for X advocacy"
3/n: Instead of partnering to re-imagine a design-outcomes-friendly flow of product development, the focus is on advocating for how design should "fit in with" or "integrate with" X (whatever the engineering team is doing).
not sure this anyone would find this interesting...but this is how I go about doing my "loops" diagrams
1. first I use write simple things like this to get connections out of my head. at this point it is very rough...
2. I get a little more detailed/structured. All the while I validate these along the way and try to involve other people (hence my initials here vs. other contributors).
3. I do a lot of these ... it gets a bit out of control. I might end up with with hundreds of hypothesis connections
anti-pattern: using one process/tool to do too many jobs
1/n teams "hire" processes and frameworks to do certain things. the trouble is that we humans get greedy. when someone says "well that does A,B, and C" we get excited. 3 for the price of 1!
The problem? ...
2/n First, it is hard to do lots of things well. The process rarely delivers across all of those jobs. It might do one thing well, but be kind of crappy at the other things...
3/n Second, communicating the Why can be very difficult. Say you have a process that is meant to promote learning/experimentation AND can be used to manage people and promote accountability.
1/n - There is so much you can do IF you accept that you have to do the old thing AND your new idea. People might look confused, but you will not get fired. Here's what I mean...
2/n - Say you work in a feature factory and features get thrown over the wall for you to "deliver". That doesn't stop you listing the various risks with that bet. It doesn't stop you describing the higher level bet/rationale.
3/n - Nothing is stopping you setting up a decision review a couple weeks after the thing has been "delivered", and your team has moved on to the next project. "We expected this ... but this is what happened.." (tip @Amplitude_HQ helps with this)
🧵a huge challenge with scaling B2B SaaS is the exploding complexity problem.
through heroics and brute force you can try to contain the problem...until you can't. At which point it consumes everything.
Why does it happen? ... (1/n)
first is the general non-linear nature of the problem
innocently we imagine that adding a new product (or person, segment, etc.), for example, is like going from 10 to 12. Instead, it is like going from 10 to 20.
you quickly overwhelm systems designed for linear things...(2/n)
second, is that the exact efforts to contain the problem at first -- the heroics, the longer hours, the more complex meetings, the project plans, the dependency wrangling -- HIDE THE PROBLEM.
It just gets soaked up into our brains and our processes (3/n)
the distance between those adding complexity to the business and those having to deal with the increased complexity in day-to-day decision making
without healthy feedback loops, you can get a massive increase in complexity before the alarm bells go off
in addition to pure distance (hops between people), you also get some interesting effects.
experienced ppl tend to notice the early signals, bc they are able to juggle the ramifications.
e.g "for *that* persona we'd do this a bit differently..."
...less experienced team members may not notice as quickly. They will artificially reduce added complexity and/or just not do anything with the extra cognitive load.
While external forces definitely play a role here and may limit your options, this is an area where a lot of pain is self-inflicted.
managers: "why aren't they pushing back?"
team members: "I never have a second..."
How can you turn the tide? ➡️
1/
You can almost never agree to something w/o something else suffering. A good habit here is to identify the thing that will get less attention, and say it out loud.
To focus on _____, we’ll probably need to de-prioritize _______. Have that answer ready.
2/
It is important to visualize *all* of your work, not just the work in work tracking tools.
Whenever I see ppl brain-dump *all* of their promises, it is far more (like 3-4x) than they immediately acknowledge.
product principles are underutilized, and often phoned in.
key symptoms. they:
* aren't opinionated enough
* don't get the cognitive gears turning
* don't help guide decision making
* reveal nothing about the strategy
* are generic and yawn inducing
how do you fix them? (1/n)
Start with a simple prompt:
When faced with a decision between ____ and ____, we tend to favor ____ because ____
Ideally this is coherent with your actions and past decisions. If not...now would be a good time to start 🙂
The best principles...(2/n)
...cause a bit of friction/tension.
You pay attention. They are forcing functions.
e.g. at @Amplitude_HQ we aren't focused on analysts working in isolation, so we might say "we are biased to scaling data literacy over enabling lone hero analysts"
just occurred to me that part of the product managers job is to frame decisions in a way that actually INVITES disagreement, dissent, challenge.
let me explain
it is easy to frame things that ppl will agree with (1/n)
..lots of successful product managers are good at this. The problem is that they aren't inviting other perspectives. They frame it up -- nice consultant like -- in order to sell the direction.
Nods all around. YES. But months later...
(2/n)
That approach gets things in motion quickly, but it doesn't lead to the best decision quality.
Now other people are so vague that neither support or dissent are possible. There's nothing to go on. No rationale whatsoever.
the idea that remote is universally good for introverts (notwithstanding the many variations of introversion) is problematic...
1/n First, to create *any* environment that is safe and inclusive takes intention and care. It is not magic...introvert * remote=good.
2/n Case in point, there are many in-person work environments that are intentional with respect to the needs of introverts. And many remote environments that aren't...
3/n In many newly remote settings, you simply see decision making shift to smaller, select groups.
What feels comfortable and easier, is merely a reduction in collaboration, healthy tension, and transparency.
Possibly "easier" for the introvert. But not in the long term
Since writing about feature factories in 2016, I've since started to referring to some orgs as "functional feature factories". What do I mean?
they deliver reasonably usable work, things don't feel dysfunctional, the reflect/adapt on how they work, but...(1/n)
12 Signs Post 👇
...they still haven't really cracked the nut .... where product development becomes the key driver for sustainable, differentiated, ethical growth and impact.
And in many ways this is a tougher situation to grapple with because stuff isn't obviously "broken".
Arguably...(2/n)
...for many companies this is a step up from what was happening before.
So you have an issue with complacency. Why shake things up? The company is doing fine?
In many industries you can survive and even thrive...to a point. Until cant (3/end)
here's a bit of advice I give to a lot of companies at my day job (@Amplitude_HQ ) re: analytics
Start By Counting Things
Skip magic metrics.
...goal setting and success metrics.
...trying to "justify" a strategy.
..."benchmarks" and what your competitors do.
Instead...(1/n)
...focus on counting things that happened that you care about. Stay firmly grounded in the customer domain. Name things sensibly. Add extra context with human understandable properties. Decouple counting from the interface-de-jour.
Start By Counting Things
Why? ... (2/n)
...this is the muscle you need to build.
When you can count things, the rest falls into place ... especially with a product like @Amplitude_HQ which handles the nitty/gritty of making that data useful for you.
too many teams jump straight to a silver bullet (3/n)
"The engineers on my team just want to code. They don't want to have anything to do with product. They just want specs. What do I do?"
1/n Are you asking them do to X *and* do their "day job" as defined by their managers (and frankly your roadmap) ?
If so, start there...
2/n Do they have a reason to believe that doing X will in any way improve the quality of the product and make their lives easier? Have they ever seen X "work" ?
Show don't tell.
3/n Is there average day/week a quagmire of unnecessary meetings, wading through tech debt, struggling to get *anything* to work ... and jumping through process hoops to prove their worth?
I think ppl look at [popular tech co] product management advice and think "oh goodness...the rigor!"
...when in fact it is really about the intentional reduction in process overhead and leaner governance/budgeting
... this is especially important for bigcos believing they "don't have the 'talent'" to operate like X
...when in fact they don't have an environment where talent can flourish like X. They have trouble letting go.
... part of this is pure $.
They might be a money printing machine, but highly highly risk averse.
They talk about "innovation" but it is in the context of a massive amount of inertia to shave off %pts in cost and a very shallow excel-drag-to-right revenue forecast
I'm going crazy trying to explain this seemingly basic concept, but striking out. Any ideas appreciated!
At the day job (@Amplitude_HQ) I meet teams who imagine the following...that there is a linear relationship between analytics instrumentation "work" and insights ... (1/n)
Meanwhile - the teams that are actually doing the work (and integrating it into day-to-day product work), see something that looks more like this...
A quick pass at instrumentation unlocks a lot of valuable insights. Integrating it into day-to-day work unlocks even more (2/n)
Can't put my finger on the why
With a self-service analytics product, it is 1) easy to add new events, props, etc. and 2) you have a whole variety of insight variations.
With just 2 events, 5 props each, and a handful of user properties you can answer LOTS of questions (3/n)
How should product managers and designers share certain responsibilities?
wrong answers only.
Pm: I pick the right things. You build them right ...
Pm: oh hey for that work we’ve been talking about that is five months out ... do you mind just whipping up some mocks? Nothing serious. Promise. Will not hold you to them.
I frequently encounter leaders who believe their team(s) aren’t “ready” for taking a more outcome focused approach. They talk of “baby steps” and “learning how to crawl before...”.
Here’s what they are missing
... to learn something, it is important to practice the thing (1/n)
You don’t learn this by running a (or working in a) feature factory, cranking out the stuff sprint by sprint.
You learn by doing a version — albeit probably more controlled/structured — of the thing ... (2/n)
What might that involve?
- direct contact w/customers
- some ability to “sense” outcomes qualitatively/quantitatively
- a feedback loop
I've meet execs who swear "we can't do X because we can't hire engineers like [big tech co]". Are they right?
and others who say ... "all you need is psychological safety and empowerment and ppl will figure it out"
hmm (1/n)
... I'm reminded of an environment that had an extremely strong foundation of quality (and safety, and empowerment). And exp. leaders.
In that env, a new grad would take 2-4y to really start figuring out the product thing. AND...would start contributing quickly.
and.. (2/n)
... another env with very talented/experienced folks all with 10+y experience, being mired in complete insanity. Things falling apart. Bureaucracy. Toxic company politics. It was terrible. Many people left. Some people stayed in a Sisyphean effort to fix the org.
37 added to My Authors
