Haters will say that "build is only the first step of build-measure-learn" but that's not actually true! After hunting for product-market fit, the second favorite activity of product managers is making a roadmap (in reality, what they make is a delivery schedule and not a roadmap, but I digress).
A roadmap typical roadmap is a 3-month block of features the team promises to ship, broken down into 2-week "sprints" (this is what makes it "Agile" and not "Waterfall"). What you won't see on that roadmap is a slot for "time we will spend redoing the work after we find out we fucked up."
Don't be silly - sure, roadmaps include time for testing, but no-one has ever allocated time to FIXING the stuff the tests show doesn't work! When I pointed out that this was kind of a major failing, the producer told me "Well, everything's just gonna have to pass testing, isn't it?"
So weird how the entire industry is obsessed with monitoring productivity, but there’s basically no consideration or accountability for technical debt and making terrible shit that conveniently becomes someone else’s problem.
So build-measure-learn does not actually translate into fixing any mistakes, because the feedback loop only fits into the timebox once. By the time you have built, it is time to build the next thing. In this context, the knowledge that the thing was the wrong thing to build is merely a burden.
This is when product managers wake up to the fact that they have all these user researchers sitting around day-drinking, and run after them for help. But instead of research, they need help with something called "validation" which is where we prove we were actually right all along.
Since we do not care what, if any, problem we are solving, validation is the perfect tool. "Find us a story that proves us right." There are various names for this. @miniver.bsky.social calls it decision-based evidence making. Wikipedia calls it Morton's Fork. Either way it's malpractice.
Astute readers might ask - if not from research, how does the initial thing being built actually get defined? I'm glad you asked. Items get onto the roadmap through a process called "ideation" which is when product managers think up things that would sound cool in a case study on their LinkedIn.
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.
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'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.
And what they "learn" is always "users need more features in v2". It is almost never, "we built the wrong thing" or "our process is broken" or "next time we should start with a real unmet need"
Oooh, you should definitely tell people about the idea of "tech debt". It's one of the dumbest things ever and would blow the mind of the average person.
You should really put an age-rated content warning on that post. Any mention of tech debt is traumatic to adults. Well, it is to this one.
Not the only one. Add "research/design debt" in there too. Butt shivers.
Now you're just describing my last project :D
Velocity tradeoff as leverage is a reasonable choice to make, and any architecture contains any number of now-suboptimal solutions you have to live with. Then there’s shitty planning, shitty practices and shitty maintainability, which are different problems. Which ‘technical debt’?
Agile allows us to be flexible and adapt to new information! But also we don't want to go back and change anything we built because the main number we care about is velocity!