Fluency, Frameworks and "Eff It"
Design is Dead? Agile is Dead?
Linkedin is full of posts that:
- espouse ways of working or models of working
- say things like "a product manager must use these frameworks to be successful"
- state "X is dead" and if you're lucky, why (agile, continuous discovery, kano, RICE, etc)
- complain about some specific use of a way of working conflating it to all places that might do some variant of it
I saw one recently that was refuting all frameworks altogether. That the best Product Managers or Engineering Managers they had observed, had never used them.
Can all this be true simultaneously?
Short answer: yes.
But I want to address one specific flavour of this:
- That observing someone working isn't necessarily a way of learning what frameworks they use.
- that the level of fluency in frameworks and ways of working can affect how visible they are to observers
Let's have a go at explaining this.
A scenario
A Product Manager is holding a meeting with their colleagues, collectively deciding what to make or not make. Maybe some "blue-sky drinking" has occurred.
Someone raises an idea: "we have this idea on the backlog where the user will have an extra button next to 'book a demo' that says 'tell me more'"
The Designer says they aren't keen on the idea. They are concerned that having two things for the person to choose will make it less easy for the user to understand what they need to do next.
The Engineer says they aren't keen on the idea. They are concerned that adding an extra button that goes to a different page will increase the support overhead handling two pages rather than one.
The hidden work
Both of these people can be right, or wrong, depending. And they likely used knowledge from their training or previous experience to explain their comments.
What they didn't do was:
- explain the basics of user centric design as it applies to modern web design
- explain the frameworks or ways of working they used in user research
- explain the frameworks or ways of working they used as part of engineering support (ITILv4, devops, something else)
- explain what criteria they used to consider these concerns worthy of raising.
All those years of experience of likely thousands of frameworks and mental models and design principles, not visible. What you got instead was a clear statement about the piece of work they are doing today, together. In plain English, without excessive jargon.
To people who are new to these professions, or even those up to mid-weight, all of this can look invisible. Almost like no frameworks at all.
The curveball
There's another reason why this happens. Lots of people in software have learnt most of this on the job. They might have even worked it out from first principles and not even realise someone has written a book on something they did in a side project at some point. In addition, the wording they start with will come from their individual specialism eg design, engineering and product have all "invented" something useful that they weren't aware existed in another area, eg Design or Marketing.
When this happens, people use different labels and words for the same concepts. So if you've been around a bit, you tend to use your framework jargon carefully - will it work with your current team and colleagues? Or you may eschew them altogether and use plain English terms, or invent your own new words as a team to encourage ownership of the way of working.
What about fluency
I'm going to borrow something used in educational and professional qualifications in the uk, where a course or qualification tries to assess how "fluent" someone can be with the subject matter.
They adapted this from Bloom's taxonomy of measurable verbs, which try to describe different levels of understanding on a topic:
https://www.utica.edu/academic/Assessment/new/Blooms%20Taxonomy%20-%20Best.pdf
So, let's say we apply this to something like a user story:
“As a visitor to the website, I want a ‘Contact Us’ button on the homepage so that I can easily reach customer support.”
- Remember / Recall
What are the role, goal, and benefit stated in this user story?→ Basic recall: Can you identify the core components of a user story?
- Understand / Comprehend
Explain why the user wants a ‘Contact Us’ button. What problem does it solve for them?→ Do you get the purpose of the story, not just its literal text.
- Apply
Write one acceptance criterion in “Given-When-Then” format for this story.→ Straightforward application of knowledge about user stories and testing, assuming you know the Given-When-Then format, otherwise substitute with something else, eg "write some automated testing scripts for this story" could count here.
- Analyse
Examine the assumptions behind this user story. Are there implicit expectations about website design, user behaviour, or business priorities? How might these assumptions affect implementation?→ Requires breaking down the story’s context, revealing hidden factors that might not be obvious at first.
Imo, this is where the juicy stuff starts.
- Evaluate
Critique whether a user story is the best way to represent this requirement. Could this need be captured as a design task, a requirement document, or something else? Support your judgment.→ Moves into meta-cognition: you must question the approach, not just the story content.
Imo, This is where good retros live.
- Create / Synthesise
Propose an alternative way to capture and communicate this requirement that might better serve developers, designers, or testers. Explain why your approach could be more effective than a traditional user story.→ Highest-order thinking: designing a new process or artefact, showing understanding of communication, context, and purpose.
Tbh, a lot of people mildly augment something and think they are doing 6 - that is another post for another day.
Quiet knowledge is like quiet luxury
Broadly, if you're fluent enough in something to be at 6, you're not talking about user stories in a way that it is obvious from an outside observer that you are talking about a user story. Which can look like "don't use a user story"!
Knowledge that deeply embedded and understood is quiet - a set of tools to use whenever, like a trusty paintbrush.
So are user stories dead?
Enzo Mari famously declared, ‘Design is dead,’ critiquing a world where design is often reduced to surface aesthetics or stakeholder value. Amongst other things, this brought about the anti-design movement in the 1960s, which encouraged more decoration and joy in everyday objects - something probably best depicted by this object from the 1990s:
However Mari was really pointing to something else - that true craft is often invisible. The fluent product manager doesn’t announce every framework or principle they use, the quiet mastery of design lives in the choices and structures embedded in the work. Design, like knowledge, isn’t dead. It’s quietly alive, guiding decisions without needing constant visibility. And that's true for user stories, agile, devops, or whatever someone is dissing on LinkedIn this week.
