This brings us to "Agile" or "ship to learn" or "build-measure-learn" or whatever your flavor of this religion calls it. The only authoritative source of knowledge is code in production. Anything not pulled in by a metrics dashboard is framed as unknowable or speculative, and can be ignored.
it's funny because there *is* absolutely stuff you can only learn by shipping but not nearly as much as these people insist there is (and shipping is the most expensive and slowest way to get that information)
I forget if it was you who said something like "the cheapest and fastest mistake is one you don't make"
slow is smooth, smooth is fast
YES! I’ve been speaking on this for years. If you’re actually trying to solve a particular problem, building before learning is the dumbest plan. You can build something wonderful that in no way hits your target because you didn’t do the user research to know where the target even was.
How was your time at IBM?
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.
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.
I’m convinced that things like “Agile” and “scrum” and “DevOps” are (successful) attempts to take basic problem-solving skills and repackage them as mysterious superpowers bestowed on only a few. What should be essential job skills turn into patented and exclusive products.
Thus proving that every word can be subverted by authorities. (“Agile” was supposed to require constant user feedback & responding to qualitative learning. It’s just that that doesn’t let executives pretend to be in control.)