This is analogous to resume-driven development, which is when software developers spend their time "refactoring" (changing code that works into code that doesn't work) the product to use the latest and greatest frameworks, for the purpose of adding them to their resume.
It's pretty much impossible to come up with an idea for a new feature from "first principles," so when product managers sit down to ideate, they are going to be thinking up all the features they are most familiar with already - features they see in software they use daily, like Google or Jira.
This is an extremely smart technique in the context of a fucked-up process that doesn't work, for two reasons: - Sales gets to put another check on the feature comparison chart - If anyone asks "why are you building this" you can say "It's how Google does it" and who are they to argue with Google?
Eventually, after enough product managers copy Google, the design pattern becomes a "best practice" and joins the canon of preferred methods that you can do unthinkingly, and then brag to your management for having done it. Don't measure results - it's a best practice so it is good by definition!
oh, I feel that. I used to work for a company that required "best practices" for its team team. Best practices for whom?? What's best for those companies over there might not be appropriate for our company. Doesn't matter. Those are the metrics.
Don't trust your people to do the best job they know how, impose out of context best on them. What could possibly go wrong? That's for the best, right?
The great thing about best practices is that you don't need to actually change what you do, as long as you adopt the right signs. "Agile development" is thus defined as: 1: two-week sprints 2: Jira 3: story points based on the fibonacci sequence As long as you are doing these, you are Agile.
I feel seen. This is the regime I now work under. We had a 25 year run as a tiny scientific instrument company that designed cool stuff, guided by grants and curiosity. About 5 years ago we started transforming into an Atlassian-driven software company. Why? Because other (huge) companies do so.
Another cool Best Practice is OKRs (Objectives and Key Results) Notionally it is supposed to be a goal and ways you can measure if you are meeting that goal. But that's hard to do. It's easy to just say our Objective is "deliver this feature" and Key Result is "feature was delivered." Boom! Done.
Aside from PMs, devs, and researchers, there are also UX designers, who escaped our narrative so far because they were too busy moving rectangles in Figma to make it to the room where decisions get made. But they are here now, because they're the most important part of copying features from Google.
As mentioned before, the PM didn't think too hard about the roadmap items beyond what would sound good. The UX designers now have to actually describe how the thing works (not so that devs can build it, devs will build whatever they want - but so that the UX designer can put it in their portfolio)
Because hiring managers spend 0.3 seconds per portfolio looking at thumbnails on the landing page, the overriding concern of this stage is making the UI look good. This is why for the last decade, we've been doing "design systems" which is when you get to do UI designs without even a feature in mind
In practice yes, though really design systems are about governance
aslanfrench.medium.com/why-design-s...
For sure. A proper design system is a requirement for semantic design. But the incentives of the industry turn visual tools into rectangle-placing apps, and design systems into component libraries, because that is the main way you progress in a career.
Anyway, this is why every website looks the same now and yet none of them actually work.
Plugging this into the thread because it's hugely important. When people ask me "what should I use instead of Agile?" I answer, use your brain
Not only looks the same, but very likely reads the same...! 🫠
@discolu.bsky.social
This is the most epic burn down on this topic I've ever seen. This should be spread far and wide. Absolute brilliance and a Hallmark for what to point to when product-and-growth-above-all-line-always-goes-up comes crashing into the earth taking jobs with it.
Alastair posted a good companion image earlier
Sigh. Pavel all of what you describe is spot-on, although a ton of it in my experience doesn't rest with the PMs, it is that PMs are unable to get buyers/*upper management*'s claws out of an OKR or ill-informed roadmap. Few and far between are the companies who empower truly user-centric PMs.
yarp
I thought it was a silly process you do, but just trust me bro, the goal is not the OKR itself, but that we just have clear goals we believe are worth working towards? that or the worst application of a practice that happens to work for mature growth hacking to everything else
Clear goals are important, but so is the clear distinction between a goal and a task.
Where I tend to see this break down the most is: - The goals that really matter the most are scoped far larger than a given team's remit - Goals around UXR that boil down to "we have understood the thing after talking to X people" - Vastly underestimating effort for non-coding R&D tasks
oh! and: "Can't we just get a design partner queued up?" --> when the task requires a busy person to do things that could potentially break their setup or their entire business no less and teams who struggle to connect with the "why" of their work when it's inherently foundational
FWIW I agree with most of your thread, this is me mostly ranting that most corporate processes take so little consideration into the complexities of what they're managing that it'd be frustrating if it wasn't hilarious
The trick is to become a monopoly and transcend the very notion of a "problem". Just ship continuously with the glossy-eyed smile of someone who knows they are safe from anything so gauche as "users" or "value". To quote the band Cheap Girls: "and if we never learn, then we are never really wrong".
Ugh. I am getting a certificate in IT project management and it is so much worse than this. You spend about 90% of your time covering waterfall and models almost no one uses and then you might get one slide about Agile that says there are many ways of doing Agile and nothing else
1000% vibes based management
There are many ways of doing Agile INCORRECTLY. "Agile methodology" is a contradiction in terms.
I'll throw in sprint retrospective where the managers recite all the feedback, but nothing is acted on.
I'd like to interject here with a brief tangent: "best practice" is one of those phrases that should set off alarms. Who says it's best? When and why is it best? It's dogmatic and should immediately be scrutinised until it's revealed to be useful or expunged.
I have a talk wherein I tell everyone to just lie on their resumés and keep shit simple. You can learn the basics of any framework in a weekend.