My product-nerd-friend @atheus...hey you should post a thread of some drawings. Here goes:
1. The classic “here’s why you do incremental delivery” drawing ... aka “how not to dig a deep hole”. Yet legacy budgeting practices encourage one/not other
2. Here’s is the “perpetual cone of uncertainty” ... namely, unless you are a project shop, you’re likely to ALWAYS have uncertainty, even if you are also reducing it constantly
3. I’m seeing this crazy symmetry in terms of systems / technology & org design. They are all feeding into each other. Exhibit 1: the shift from batch processing to stream processing (cc @gwenshap ) and networked orgs @NielsPflaeging
4. What are you willing to pay to bet on the race AFTER the elephants have left the starting gate? What if it is free, but your competitors aren’t doing that?
Yet, traditional annual budgeting prevents us from playing this (more fun) game
5. How much time is your team spending on the value-add work vs. the “other things” ? And are you trying to get at this through some weird proxy of story points, time tracking, etc.? This is a hard question for many teams to answer.
7. I love this idea of nested sense/respond loops ... if these get too out of sync, you’ll get caught in a bit of a trap ... the output loop will spin WAY faster than the benefits loop. The goal is keep these orbits in better sync.
12. And finally ... meditating on the value of focusing myopically on “the problem” vs. creating a new attract and just letting things play their course.
This is one of the biggest traps in scaling a company
Everyone should be aware of it.
1/n At some point, someone will decide that one things is working well. It is time to try 2 things. This almost always involves the assumption that there are some common things between the two
2/n But it isn't that easy.
#1 is more stable and practiced
#2 is less stable and practiced
The assumption that you can support both with common services is a little shaky. These are very different motions.
3/n ....and even that is based on the premise that #1 was actually working, and that the decision to do #2 wasn't based on a flawed premise (that #1 was working).
OR...that #1 had "flattened out" (we assume there wasn't room to grow there)
1/n it involves knowing what X is. And if you need X, there's a good chance you don't know what X really is ...
2/n
It means that you need to be able to figure out if the person really did X. Very few people operate in a vacuum. To ascribe X to one person is a dangerous slope.
3/n
It means that you are somehow able to predict whether the person can do X in your culture/situation. That is a huge stretch.
You are looking for someone who has done X ... in a similar context. Much harder
I've been reading a lot of great threads about the difference between "idealized" product management & "real world" product management.
as someone who contributes a fair amount of content, and interacts w/ a wide cross-section of teams, it has really gotten me thinking
1/n
2/n
It goes w/o saying, but one problem we have here is communicating about "the real world" is exceedingly hard! Even in books. It takes...words.
Much easier? 1) Generalized, high-level, good-sounding advice 2) Angst 3) Pragmatism ("apply in context","be curious")
3/n
One of my big challenges w/social media is that -- and I have the data to prove this -- the more angsty, pragmatic, or generalized the advice...the more it is consumed.
What actual, specific, behaviors would we observe if someone was good at product thinking?
Specific enough that someone without a lot of tacit knowledge would be able to say “that’s happening”.
some off hand
1/n
Better Proxies for Value. We'd observe them challenge a "success metric" and ask if there was a better proxy for actual value exchange. Fewer overt vanity metrics (or at a minimum, leading indicators mapped to trailing indicators)
2/n
Consider multiple options. We'd observe them weighing a range of options to achieve the same effect (vs. simply prioritizing a list). "Well... some potential experiments might include..."