Problems, not solutions (2018)

https://ben.balter.com/2018/07/16/problems-not-solutions/

by UkiahSmith • 6 years ago

122 41 6 years ago

ben.balter.com

dfee• 6 years ago

I don’t know Ben’s background, though I see his current role as a senior PM at GitHub. I also work with PMs in the heart of the bay - have done the PM role, have run operations across a few companies, and have presently returned to engineering.

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.

bxparks• 6 years ago

The concepts of "product-minded engineer" and "engineering-minded pm" make a lot of sense. But what do you mean by "reduced waste" in the context of software development?

barrkel• 6 years ago

Engineering builds the wrong thing, or more likely builds things in such a way that they are harder to adapt to features further out the roadmap.

Isamu• 6 years ago

lack of knowledge hoarding, healthier knowledge transfer and decision making, and reduced waste.

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.

tristor• 6 years ago

I agree with this entirely. I'm a PM at a company which is under 300 employees where we were founded by engineers, and nearly every member of management from the executive team down to the ICs has an engineering background. I have an engineering background of 13 years before becoming a PM. Everybody at this company is looking at and trying to understand the customer's problem and identify the best solution, and internally we have very high knowledge transparency.

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.

zippergz• 6 years ago

Totally agree. I've been both an engineer and a PM at companies large and small. This sharp line distinction between what PMs think about and what engineers do is never productive in my experience.

jayp• 6 years ago

This comment is aligned very much with my current thinking. Hiring highly paid engineers but not maximizing their problem solving ability is a significant problem in large companies.

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.

[1] https://www.heraldhq.com

vinay_ys• 6 years ago

A relatively small number of individuals are required to act as conduits of information – they should be good at collecting, analyzing, organizing and sharing information. They should be good facilitators to anchor a problem/solution across multiple teams/systems/skill-disciplines. These individuals are the PMs. As long as we don't let it go to their heads that they own the product and they are the deciders or some such notion that basically reduces everyone else's problem solving ability, PMs can be very useful.

pdimitar• 6 years ago

IMO there are a lot of good ideas how to solve such problems out there and that's not the blocker at all.

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.

NorthOf33rd2• 6 years ago

I've been a product manager for nearly a decade and I'd agree with your premise. I've released several well received products, and have risen through the ranks, probably the most relevant success metrics for my role.

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.

cocoflunchy• 6 years ago

PRDs for CYA?

citizenkeen• 6 years ago

Thank you. I'm a product manager / engineer at a small logistics company, considering the future. I'm good at product management and I'm okay at programming but I really like doing both. I was worried there weren't a lot of opportunities for me to do both, but it sounds like there are. Thanks for the insight.

asciimike• 6 years ago

Developer tools is an especially great place for technical PMs who want to continue coding. It lets you design interfaces and test implementations (building sample apps, live-coding demos, etc.) without I would consider the daily grind of software engineering.

Lots of dev tools companies getting funding now as well, so plenty of opportunities!

protonimitate• 6 years ago

My company is going through a dynamic shift to more closely align to the "best" situation you outline here.

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.

benbalter• 6 years ago

A lack of knowledge hoarding, healthier knowledge transfer and decision making, and reduced waste.

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.

brightball2• 6 years ago

Agreed. It's one of the biggest things that drew me to SAFe as well because it fosters more communication and collaboration, empowers more people to make decisions and specifically de-emphasizes the PM as a focal point of all things.

someone7x• 6 years ago

And, while I’ve not seen it coined, I’ll introduce “engineering-minded pm”.

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.

userium• 6 years ago

I agree, and that's why I'm a huge fan of Hypothesis Driven Development, which enables the whole team to know whether they're adding real value to the end-user. Usually, it's embraced by, using the term you coined, “engineering-minded pm”s, who understand the importance of developer happiness and thinking in terms of problems.

baldeagle• 6 years ago

I'm a few years into this Product Manager journey, and I think this is the level 1 of Product. The basics are to focus on the pain and customer need instead of just grooming features that come in and delivering those features. If you have trouble with this, I like to use a focus / flare / focus model. First think through your solution (privately) and list out the benefits and drawbacks in terms of your user experience / needs. Then double down on imagining your user interactions and actually go talk to them about the idea. Pay a lot of attention to where their reality and your assumptions don't align. Be very curious. Then with that new grooming of the customer experience, focus on how to communicate the meaningful pain points to your engineering team. If needed, you can even walk them through the journey you took. At the end of the day, the more you can get them to empathize with your chosen customer, the fewer blindspots they will have and the better their intuitive solves will be.

Invictus0• 6 years ago

I've definitely seen some examples of over-technically focused engineers, but this piece goes too far to portray engineers as hapless sheep that need to be herded into a useful business purpose, lest they wander too far into an interesting technical problem and never return. Establishing problem requirements and definitions is something every engineer is trained to do and is really not such a difficult thing to do, but once that's done it's no longer the primary job focus.

jtdev• 6 years ago

As a software engineer and manager of software development teams, I disagree; very few software engineers in my experience are able to approach problems without injecting their desire to use shiny new toys, rewrite entire systems (simply because the existing code is unfamiliar to them), shoehorn patterns that are a poor fit, etc. it’s honestly a major problem in this young field in my opinion. I think the article outlines some good pointers to avoid these things and instead focus on building software products more purposefully.

jklm• 6 years ago

Building a solution in search of a problem might be the classic engineering pitfall, but reading the title made me think about the flip side of that.

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.

Vysero• 6 years ago

"...given a sufficiently defined problem, the solution is often the easy part...The real challenge lies in understanding customers’ true needs"

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.

paulsutter• 6 years ago

“Customer Analyst” is a much better title for the role held by “Product Managers”.

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

sitkack• 6 years ago

Exactly, my current exposure with PMs is that they are feature driven, not focused on problems specifically. And as someone who works with customers in pains me deeply when they just don't get it. The customers, the ones who will use the product are right there and they have no relationship with them.

habosa• 6 years ago

It seems like every PM has a slightly different job from every other PM, even at the same company. Across companies there's absolutely no comparison.

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.

bothra90• 6 years ago

The fact that PMs are empowered to be "CEOs" of their product probably doesn't help. In my mind, transparency in the 2-way communication between PMs and engineers is key. Engineers need to be motivated by the "why", but PMs also need to understand why an engineer might want to, to quote from the article, "spend months refactoring an app to make it “right”".

imvetri• 6 years ago

Product managers are just working for business. They do not think, they just obey.

AtTheLast• 6 years ago

By understanding the problem, you can bring multiple people together to figure out how to solve it. We all have different skillsets and sometimes the best solution isn't in our skill set or is a combination of skill sets.

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.

ineedasername2• 6 years ago

> customer comes to you asking for a 1/4” drill (a solution). Their stated problem may be the need for a 1/4” hole, but what they’re really after is the ability to hang a picture

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.

floatrock• 6 years ago

This blog post (and your key question) is basically "how to avoid that what-the-customer-really-wants tree swing image".

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.

ineedasername2• 6 years ago

That's a great visual, I may actually use that in training both other developers and when begining large projects with constituents.

29athrowaway• 6 years ago

The next iteration from "fake it until you make it": "fake that you are making it"

asplake• 6 years ago

Halfway there – needs & outcomes are where it’s at. If it’s not meeting needs, what’s the point?

Problems, not solutions (2018)

Related Stories