New blog post and video on having a growth mindset!
If you work at Microsoft, you hear about having a “growth mindset” a lot. But what does this actually mean, and how does having a growth mindset apply to growing and thriving as a PM?
Remember that your phone battery indicator is lying to you. Other customers didn’t like to see the battery indicator deplete as soon as they took the phone off the charger, so they complained to vendors. Those built a lie to accommodate: the indicator now lingers at full capacity longer. #progress ? #productmanagement#ux#userexperience
One common 101-level financial literacy comment is that "your house is not an asset". (I mean, technically wrong because it's an asset, a liability, and a source of costs but we get the point.) In #ProductManagement all new product scope is like this - scope is a liability, guaranteed, while it's not certain if there's any asset in anything you keep adding.
If Agility is the ability to respond to changes in a meaningful way, a huge part of that consists of the time it takes until this response is in the hands of the customer so that a feedback loop can form.
If that's true, what's the value of Discovery Epics or Stories, Spikes, Dual Track whatever...
@RosannaSibora This paper-thing has no value for the users. A small group that's hardly representative for the real needs of users is given something to play with, instead of the real thing, a proxy. Then the proxy is thrown away, which is waste. Then a handover from those good at building proxies to those good at building the real thing happens.
Gained knowledge and hence risk reduction is uncertain, if not questionable. But a lot of time and capacity is used.
I'd argue that this proxy represents a mental model of the potential solution. It's a tool for thinking, aligning and learning fast as a team. In my book, this is not waste. Also, I'm not sure I agree with your assumption that some of those who built the proxy needs to be different from those building the real thing.
When you construct any physical thing, it's very helpful to first create a design on paper IMO.
(Agree that 2 week milestones is an agile anti-pattern tho.)
@denis That treatment of product work covers what Buxton calls “getting the design right” but it falls a bit short on the problem your piece is focused on, namely“getting the right design”.
The core contract between product and engineering is that product will derisk the work and provide strategic cover. How they do that second thing is mostly a dark art.
Please, do not start your decision making processes or tickets with solutions.
Start your processes describing the problem you want to solve and the expected outcome. Let the team - people who will implement it - define the solution collaboratively.
If you (manager / boss) define the solution and expect the team only to implement it, you are just a #featurefactory and not an empowered, agile team. This is #agile in name only, a superficial one.
Trying to improve the wrong dimension of #UX will only lead to waste. Learn the difference:
Wonky products are confusing; their mental model doesn't match the user's. Janky products are conceptually fine, but buggy or inconsistent.
Jank manifests only at the hi-fi stage of development, and can be solved by UI redesign or backend optimization. However, wonk must be caught at the conceptual stage with lo-fi tools. You will NOT be able to fix it on the #UI layer.
I adore this model because it approaches the old question of "is the problem in the concept or in the implementation?" in a way that asks "why not both?"
I detest roadmaps. Roadmaps have dates. I never deliver on a date far ahead. I deliver when it is done now and prepare for what is next and later. Pipelines are way more efficient and better suited to prioritize new ideas! #productmanagement#productowner#pm#po#product
It's easy to say #Agile has failed - but it hasn't. Rather, the entire framework of "building good software" has failed. Our leaders consistently set goals like "do Agile" rather than "build good software" because it's a lot easier to set the former goal rather than the latter.
But there is an analogous domain that shows us an example of how to build a better relationship with our tools.