An important part of my job is a thing called "user research" which is where you talk to people who use (or might want to use) your product to understand their problems, so that the thing you build ends up being useful for those people. The most common view of user research is "it slows us down."
Too real.
📌
Now, this is technically true! A process that takes time to do user research takes longer to complete one cycle than a process that is exactly the same except for no research. However, the thing that comes out the other side is shit. But this is only an issue if you care about solving a problem.
In my field (training and development), the late Joe Harless was known for saying "an ounce of [needs] analysis is worth a pound of [training] objectives." In sane organizations, "code shipped" is about as sound a metric as "PowerPoint slides shown per minute."
Since the default decision-making mode of tech is picking the method FIRST and the problem SECOND, it's really not that important that the method doesn't solve the problem. The successful outcome is that you got to do the method. If it didn't work, we will simply "pivot" (pick another problem).
And thus, using product practices from tech orgs that aim to find a market for what they made will not work for most organizations. Because the org has a defined problem they need to solve. The problem is the constraint.
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.
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!
When you're a hammer, the whole world looks like a nail.
This explains so much about the software I have to use.
They'd rather build the wrong thing quickly.