One problem with the meme that building products is about "solving problems" is that the biggest successes often come from recognizing very vague "problems" others don't, in the form of seeing fundamentally better ways of doing something -- without being able to grasp up-front the long term concrete benefits. You need to build and ship to learn them. So in those scenarios, people don't recognize what you are doing as a "real" problem, so it ends up being hindsight bias when it's recognized as such. An example in the article cited was Wikipedia: Wikipedia didn't "solve a problem" with existing encyclopedias, it recognized there was just a fundamentally better way to collect objective knowledge and disseminate it -- most people at the time were scratching their heads about what the point was, since from their perspective encyclopedias worked perfectly well within the scope of their design goals.
I think the mental model that you should always be working on software where you have people directly telling you the problem they want to solve is a poor one -- it's great for a variety of domains, but often people want a faster horse or don't even see a problem with their existing horse. Even when you think you are recognizing a problem others don't see yet -- it can require a leap of faith to begin exploring to see if you can iterate and react to discovering something with big promise.
The comparison to hill-climbing algorithms is an interesting one, especially because the author ignores the fact that hill-climbing algorithms get stuck in local optima unless there is a way to “restart” the search from a new location. There is a time and place for big, risky changes to advance beyond what this “patch” approach can do.
I think this is what happened to Amazon. A series of locally optimized decisions like commingled inventory and 3rd party sellers that has turned the site into a used car dealership in some categories.
The rarest skill, even in highly intelligent engineers, is to be able to imagine the world after a thing has been changed, and see what will matter to people then.
Everyone else (including you, most likely) can only see the change itself. Is the change pretty? No awareness at all of whether the product after the change is nicer than the present product.
It is a skill that can be developed, but it takes focused attention. The end result is to see how to alter the change to make the end result better to use, not just a thing with another PITA feature.
But is a huge trap to get stuck on try to first define words, like "Simplicity" as if the fact some concepts are hard to define in highly PRECISE terms are a real impediment or block
Simplicity, like love, justice, elegance, etc are hard to define, but EASY to see.
How you know something is "complex"? When is not simple. When you know something is "complicated?", when is not simple, and not even complex.
The fact some concepts are hard to articulate is not a big problem most of time.
What is needed, is to ASK IT. Ask yourself "is this simple?" "no, we think is complicated". Pump! that's all.
You don't need to get lost on definitions to know. You only need to ask.
----
P.D I don't argue against the importance of definitions... and sometimes people are sooooo lost or the project is sooooo messy that actually is necessary to make a mental check to make clear to everybody or ourselves, like @revskill say, to be more precise in what we are talking about. But most of time, is a problem of FAULTY COMMUNICATION not on words!
Having done a bit of tech writing, "how hard is it to explain" is my proxy for simplicity / complexity.
I've read everything I can about measuring complexity. I'm just not smart enough to understand most of it. So "simple" is still like pornography for me: I can't define it, but I know it when I see it.
How many new concepts a new user needs to learn, and how many mental models a new user must develop in order to effectively use your software.
Twitter is simple, Git is complex.
Twitter is simple only at the UI level. It’s still very easy to make a seemingly simple move on Twitter which results in ending your career, signing up for a life of harassment, etc. In a way, Twitter hides too much of the complexity of the world.
I think this is close to a pretty good definition, but it should be restricted to people who already have learned the mental models of the domain. In that the mental models learned to use the software should match those of the domain.
What is being described here is very similar if not identical to what can be found in Agile software and lean software development books that gained popularity in the mid 2000's.
No it isn't. Agile software development assumes management knows what it's doing - which is often not the case at all.
Agile is primarily about managing down assuming a coherent goal exists - not about finding the best coherent goal when it doesn't, or even about being able to tell that it doesn't.
Agile business management doesn't really exist as an established practice. Although you can certainly find books, consultants, and all the usual noise that use the term, the idea that you can recursively define your business strategy - not your implementation - by solving the problems that provide the best customer satisfaction at the lowest implementation cost isn't as common as it should be.
The obvious complication is that the definition of "customer" varies. A bootstrapped startup needs to focus on real income-generating customers.
A VC-funded startup is in a different market. The primary customers are actually the VCs and other investors - not product users, whether they're paying or not.
Pieter Hintjens is always worth reading, even though his "solutions" are wildly oversimplified and contingent. Here he takes it for granted that solving customer pain points should always be the primary value-generating goal - which for better or worse happens not to be true, especially for startups.
I think the mental model that you should always be working on software where you have people directly telling you the problem they want to solve is a poor one -- it's great for a variety of domains, but often people want a faster horse or don't even see a problem with their existing horse. Even when you think you are recognizing a problem others don't see yet -- it can require a leap of faith to begin exploring to see if you can iterate and react to discovering something with big promise.