There are two problem-solving approaches:
1) identify a problem that you want to solve, then find a method that will solve it
or
2) pick a method you want to use, and go hunting for problems.
The second way is the stupid way, so it shouldn't surprise anyone that it's the default method in tech.
1) identify a problem that you want to solve, then find a method that will solve it
or
2) pick a method you want to use, and go hunting for problems.
The second way is the stupid way, so it shouldn't surprise anyone that it's the default method in tech.
Comments
The stupid are the people who buy the tech, in DROVES, to solve problems a marketing department just made them aware they have.
If organizations were already applying them, there would be no need for ITIL.
(Says this person who has delivered hundreds of ITIL trainings to thousands of people.)
I haven’t seem many cases of that.
( what NYC did with Manhattan Bridge —just kept up painting it blue Until it need extensive work ~2094)
Trump has decided our research on trans healthcare should be only about the downsides and are looking for people with regrets to source information from. They have the results they want to be true, now they have to find a way to pretend its real.
create a problem, codify the problem into law, then sell a short-term solution that will never fully solve the problem
Developers love to build 'em...
✌️😊💙
who cares where they come down?
That's not my department,
says Wernher von Braun
Ideally, marketing would say "this is what there is a demand for, go make a machine for it.".
What we have instead is engineering saying "We made this thing, go find a market for it."
Why would you do that?? Because the core sacred devotional activity of tech is developers writing code. Everything else warps around that act.
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.
The most common view of user research is "it slows us down."
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 sane organizations, "code shipped" is about as sound a metric as "PowerPoint slides shown per minute."
If it didn't work, we will simply "pivot" (pick another problem).
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).
(“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.)
Powered by @skywriter.blue
"If all you have is a hammer, everything looks like a nail".
Identify the problem you want to solve, and solve it in a way that creates more problems.
Profit from selling the "solution"
Please unroll
Powered by @skywriter.blue
Today’s tech genius: yeah so we have this thing that eats entire civilizations and vomits up the worst things imaginable and will probably destroy us all, how can we use it to make better porn?
you talk about incompetent PM's who think they are the smartest in the world
i did agile dev for 20 years taking into account final users at the very beginning of the evolution process and rarely faced the situation you describe
🍉🔨
"Or maybe that."
🦶🔨
"OW!"
It's a really nice luxury to have.
Most folks in this world are not as fortunate as we are in the West.
Folks solve problems so they can eat, or keep their families from getting hurt.
I'm grateful to be fortunate.
At the same time tremendous numbers of successful tech products have been built in the last 30+ years so a lot of companies must be getting it right. Including some that seek PMF and “pivot”.
I’m pointing out that there are survivors despite this “default” and so perhaps there are multiple routes to success. Wouldn’t it be interesting to explore the other factors and circumstances to learn more? Is it all just luck?