Problems, not solutions (2018)(ben.balter.com) |
Problems, not solutions (2018)(ben.balter.com) |
I think this characterization of engineers is off, and in a way that appears to inflate the value of the PM role. It’s taken from (a PM’s) ideal perspective of himself, where he is the gatekeeper to the business knowledge of the organization. They know the “why” and the engineer knows the “how”.
Now maybe at a huge organization, this ideology gets entrenched - but at companies smaller than (let’s say from experience) 300 people, this is neither correct nor best.
What’s best - I believe - is the increasingly popular concept of “product-minded engineer”. And, while I’ve not seen it coined, I’ll introduce “engineering-minded pm”.
What’s the difference? A lack of knowledge hoarding, healthier knowledge transfer and decision making, and reduced waste. I’m not even going to think or talk about increased velocity, just reducing the waste will naturally increase focus and take care of many other problems.
Author here, +100 to this. The role of the PM should be to drive consensus around the problem, not to decree the problem (or requirements) by fiat.
For me, that process is highly collaborative, and engineers (and design, support, etc.) should 100% be involved from the begining. The amount of definition will vary from team to team and even engineer to engineer, but if a PM is hoarding knowledge, their understanding of their own role is the opposite of what it should be.
To paraphrase a famous product manager at Initech, "I talk to the customers so the engineers don't have to". That's not to say the engineers shouldn't talk to customers, but generally speaking, PMs should be the ones conducting qualitative and quantitative research day-to-day so that everyone can focus on what they do best.
At least on my teams, for example, user interviews are recorded and shared with the entire team, along with their raw notes, as are the high-level takeaways, allowing everyone to opt-in to as much or as little context as they'd like. We treat quantitative research the same way, sharing the underlying query, raw data, etc.
While the PM may ultimately drive the discussion, problem definition should be collaborative so that the entire team is aligned around a shared product vision. The PM's role should be to gather, organize, and share knowledge to build consensus, not to hoard it.
This. It is so much more efficient as an engineer to have a clear idea of the values and needs of the users, and to share a clear vision with the pm of where the product should be going.
That said, at most places there is an almost total lack of appreciation for the amount of engineering and planning and effort that goes into providing a competent, professional product when those tasks are not directly providing customer-facing features. But it's part of the engineer's job to educate the pm as well about unappreciated realities.
I tend to favor less documentation and more communication overall. My tickets/stories whatever, are generally very light and my focus is on honesty and making sure the team understands the problems we're looking to solve- and why. Sometimes that takes the form of "because my boss's boss says so, and we just gotta do it." I see my role as the PR person for the team, and I do my damnedest to make sure that the work they are doing is known and appreciated. Also, I love a good fight with the PMO and making sure they aren't trying to shove dumb process down our throat.
If I have a team that can do good work, and people in the organization know about it, everything seems to shake out fine from there.
This doesn't work with every team. If they have a history of being blamed/battered by management for "failure" this approach is always rejected and the team wants detailed PRDs for CYA.
Previously engineers were presented with functional requests, i.e. solutions, and not feature requests or problems.
E.g. a lot of our stories were defined as "set a value on page foo, display it in table bar" without any context. This caused a lot of frustration on the engineering side because we didn't know why we were doing something, and were never given a chance to actually engineer something. It was compounded by the fact that these "solutions" were often reversed or made obsolete a month later by a new "solution" that could have been there from the start.
Thankfully, we've started having the real problems brought to the engineering side and work together with product management to come up with a solution. Yes, this means more meetings, but in the long run we're saving ourselves a ton of time un-doing work and avoiding traps in the code early on.
I firmly believe when you remove the "why" context from the conversation with engineering, you lose time and, more importantly, trust in the product team. I've not once come into contact with a product team/person who can accurately translate the "why" into the "how" seamlessly.
The most value I, as an engineer, get from the product team is their help in prioritizing work and coordinating across teams. Let us solve problems together.
Empowering bottoms-up problem solving by sharing customer pains and feedback broadly is the exactly problem I am trying to solve with my current project/startup [1].
I am gonna shoot you an email later today to see if you have any further thoughts on how do this effectively within an org.
If anyone has ideas on good implementing this, would love to learn so we can incorporate this within our offering. My email is in my profile.
The real problem are the managers who only do lip service to better policies but never actually implement them. They prefer to distrust people by default and to play internal politics games so they never get fired. Thinking how the customer can succeed better and thus bring more revenue is practically one of the last points in their priority list. Not even sure that "let the creative people figure out solutions, you just give them the problems" even exists in their philosophy.
To me those are the real issues. And they are extremely hard to solve because those people are usually deeply entrenched in the organisation, they have the ear of the CEO and are being listened to during board meetings. And when those people sabotage the implementation of a policy that can improve the company's culture, well, there's basically almost nothing that can be done.
I might be too pessimistic but I've seen this scenario several times and have grown quite cynical about the ability of companies to change their DNA at all.
I have been in large organizations before as an engineer where the PMs were separated and basically set marching orders, but that's not the way smaller organizations operate.
High knowledge transparency directly translates to consensus building over dictatorial decision making and ensures that the engineers know why they're making a specific choice. I think our high-quality software clearly comes from this advantage.
You might enjoy Inspired by Marty Cagan: an engineer evolves to a new role that we later come to call Product Manager. A core tenet I remember is that Product is greatly served by having engineering acumen.
Lots of dev tools companies getting funding now as well, so plenty of opportunities!
What I've noticed at Google is that through a combination of personality and bureaucratic convenience, the PMs have taken over completely. I like the PMs I work with so this is not necessarily a bad thing, but I don't think it was intentional. When we're trying to launch a feature or make a big product change everyone just accepts that the PMs word on if/when we will do it is law. If we disagree with the PM we simply escalate to a more senior PM. I don't think it was meant to be this way, but nobody else is empowered to make these kinds of decisions so it falls to the PMs by default. Plus they tend to be very well connected across the company because they work with everyone, so they can make things happen.
Yes, this. I began delivering much better solutions when I began incorporating, "okay, I can build that, but what do you want to do with it?" at the very beginning of any requests I receive. I'd say it's about 50/50 on whether the initial request would would meet the desire completely, or fail in part or in whole.
https://www.google.com/search?q=what+the+customer+wants+swin...
It's about asking the kind of questions that get at the heart of what's valuable to your customer.
More than anything engineers need to understand the customer needs. The title “Product Manager” creates confusion that this person should own product features, which is a dysfunction because the skillset to collect data on customers is fairly disjoint from the ability to make design tradeoffs.
It would also emphasize how time should be spent - actually talking to customers - rather than mostly negotiating detailed waterfall specifications that usually trail (not guide) actual product development
Is finding problems in search of a solution the classic PM pitfall? I’ve seen more than a few products suffer from feature bloat and inevitably collapse under a lack of design and UX cohesiveness.
I can’t say I’ve reached product sense zen, but I imagine it lies somewhere in between these 2 extremes. Meaning, being okay with ‘finishing’ products, but having the intuition to find and work on the next high-impact product.
I see this with my boss. He always brings feature request to me and we have to work backward to get to the problem. Then we usually come up with a simpler solution once we understand the problem.
When is the problem every sufficiently defined?
I disagree that the “real challenge” lies in understanding customers' "true needs". In my experience the customer and their needs are exceptionally easy to define, and the product managers (often times) over analyze the situation causing more difficulty which inevitably delays solutions.
I agree that customers rarely know what they want or need, in detail. However, imho the development team is perfectly capable of understanding what they actually want/need inherently or with minimal training. That’s not to say that product management isn’t necessary because it is, but is it more important to be able to suss out the minutia pertaining to the differences between two relatively equal and acceptable solutions than it is to provide a service? I think not.
While answering this, I'm wondering if the rejection of that style is also correlated with organizational use of acronyms?
Exec Manager (wanting to save face in next exec meeting) - Why did the team do that? It obv didn't work. Who's fault is this?
Product Manger - Remember we all signed off on this PRD saying we would try this approach? We also included a couple of alternative options we can explore in case the primary approach wasn't as effective as we hoped.
Upper Manager - ... (after a moment) Ok then, let's explore those alternatives.
Engineering Manager - whew
PRDs _esp those with sign off_ can cover your ass.