
A few thoughts on product management
Gone are the days when building products was about a single person locked in a room living off of the pizza for days.
Technologies and ways to build things went from a few to a multitude. This expansion equates to not only more ways to solve problems, but also more problems to be solved. Just think of technologies such as GPS and smartphones and what they brought to the table.
As a consequence of this expansion, teams have also expanded from maybe handful individuals working on "everything" to teams working on different parts of products and specializating in certain technology stacks. It is common to find back-end engineers working along with front-end engineers, working along with mobile engineers working along database experts and they might be time zones apart from each other.
The more people you have working together, the more communication paths you have. More communication paths means more chances to miscommunication. So, communicating well is just as important as writing good code.The better you coordinate, the better the chances of building good products. Building products is now a team sport.
Scope versus Scale
Organizationally and delivery-wise, what I have seen in my career is that teams will tend to gravitate towards ends of a spectrum. "Continuous delivery / figuring out users" type of teams on one end of the spectrum, and "pre-determined releases / telling users what they should like" on the other end.
Generally speaking, organizations that are focused on Scope tend to be faster paced and worry more about what users think and want. Whereas organizations focused on Scale are more deliberated about what and when to release and prefer dictating trends to users.
That would explain why startups tend to be more dynamic and why big corp tends to be more status oriented and command and control.
I bet that if you are working on the scope side of your product, there will be moments when you want or need to tell your users "what they like". The same is true for scale: even if you are on top of your game, sometimes being surprised and picking up on user's suggestions is not that bad at all.
The opportunity to be seized here is not about bringing the startup mentality the big company world or vice-versa. It is about engineering your team in way that you can create the right tension between the people looking at maintaining the status quo and the ones willing to break it.
Why the obvious things are not so obvious?
“Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations” — M. Conway
Building products goes beyond just having a number of smart people working together. It is also about how you organize and model your team(s) and create communication structures that will allow you to achieve what you want. More than that, it about how you continuously re-assess and re-structure: think agile-lean in terms of team structure. If thev world is constantly changing, why shouldn’t your product change along?
Maybe that is why SaaS makes sense to so many business models: because of its service oriented nature, it requires business to continoulsy deliver value.
Doing agile is different than being agile
I have lost count of the number of times I’ve heard: “yes, we do agile!”. You walk around the office and see post-it notes everywhere. They have their synch-up meetings and QA is involved from day one.
However, one should realize that there is a difference between doing agile and being agile. It is easy to just maintain old communication and power structures, but utilize new methods: post-its, stand-ups, “agile software” and so on. In cases like that, things might be delivered faster, producing garbage faster is not ideal.
It is about how you state problems, and how you solve them. It is about having a culture focused on deliverying value from the the user’s perspective, regardless if you are finding out what value is or dictating it.
Products as conversations
Building successful products is somewhat like making art. Every piece is unique, every artist has its own style and audience. Fundamentelly, artists develop a conversation with their audiences.
Why is that relevant? Because more often than not, PMs become the single point of failure by focusing on pushing user stories. I argue that a good PM should be seen as a facilitator, a "neutral ground" that allows and incetivizes the conversation and conducts the team (and the users) to the right place: a combination of what users want and the company needs.
