
Problems, not solutions (2018) - UkiahSmith
https://ben.balter.com/2018/07/16/problems-not-solutions/
======
dfee
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.

~~~
benbalter
> 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.

~~~
brightball
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.

~~~
rgbrgb
What’s SAFe?

~~~
brightball
Scaled Agile Framework

------
habosa
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
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”".

------
ineedasername
_> > 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
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...](https://www.google.com/search?q=what+the+customer+wants+swing&tbm=isch)

It's about asking the kind of questions that get at the heart of what's
valuable to your customer.

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

------
paulsutter
“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
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.

------
jklm
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.

------
baldeagle
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
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
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.

------
AtTheLast
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.

------
Vysero
"...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.

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

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

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

