6 ms·

Problems, not solutions (2018)

122 points by UkiahSmith 7y ago

Invictus0 7y 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 7y 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.
baldeagle 7y 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.
dfee 7y 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 7y 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 7y 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.
    - nitrogen 7y ago
      I've also seen this waste when a PM micromanages aspects of the engineering they are not familiar with, and forbids more senior engineers from thinking about the future (e.g. by refusing to allocate time for obvious foundational engineering).
- Isamu 7y 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.
jklm 7y 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 7y 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 7y 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 7y 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 7y 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 7y 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”".
deleted 7y ago
[deleted]
imvetri 7y ago
Product managers are just working for business. They do not think, they just obey.
AtTheLast 7y 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.
ineedasername 7y 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 7y 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+swing&tbm=isch 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.
  - ineedasername 7y ago
    That's a great visual, I may actually use that in training both other developers and when begining large projects with constituents.
29athrowaway 7y ago
The next iteration from "fake it until you make it": "fake that you are making it"
asplake 7y ago
Halfway there – needs & outcomes are where it’s at. If it’s not meeting needs, what’s the point?

122 points by UkiahSmith 7y 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 7y 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.

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

dfee 7y 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 7y 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 7y 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.
  - nitrogen 7y ago
    I've also seen this waste when a PM micromanages aspects of the engineering they are not familiar with, and forbids more senior engineers from thinking about the future (e.g. by refusing to allocate time for obvious foundational engineering).
Isamu 7y 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.

jklm 7y 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 7y 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 7y 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 7y 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 7y 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 7y 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”".

deleted 7y ago

[deleted]

imvetri 7y ago

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

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

ineedasername 7y 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 7y 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+swing&tbm=isch 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.
- ineedasername 7y ago
  That's a great visual, I may actually use that in training both other developers and when begining large projects with constituents.

29athrowaway 7y ago

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

asplake 7y ago

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