|
|
|
|
|
|
by this_user
333 days ago
|
|
|
Tech people don't like to hear this, but you also need product people. And I don't necessarily mean those with a business background, but those who can see the larger picture from the user/customer perspective and who can ensure that all of the technology is packaged into one coherent and actually useful thing. If the project is run by those who are all deep in the weeds of low level technological details, odds are that the larger product turns into a giant mess that is all over the place. |
|
|
I can say that tech creators tend to be able to learn product and business easier than the other way around.
One reality is too many product folks don't always know what tech is capable and possible of, which can undermine the asks and the solves. So innovation can become best practices (existing) and increments from there, instead of seeing new ways digital can be delivered.
I'm all for making fun of premature optimization and abstraction into wavy concepts. That can happen as much in product practice as it does development. Maybe the sticky consumption ratio could be part of a KPI.
When building technology solutions to solve people's problems, clever architecture will always beat clever coding and clever product people. Because you make both product and code and architecture evaporate for something simple and flexible that can actually learn and have more than few chances to become what the problem needs.
Another reality is tech folks don't need interpreters like they are sub-human or something either. It all depends how the organization and it's culture is put together to value everyone.
Where tech folks are relegated to be "engineering" it's at the peril of the organization. The more layers between the customers, their problems and those who create the solution (together), the greater the disconnect that can form as the org grows.
The solution is about a table.
A round table.
Where everyone has an equal seat and can understand it together.