Our engineering team has been building features based on ideas, and I’m the first PM. How do I change the culture and help them buy into being customer focused?

I would start with minor tweaks to the existing process vs trying to completely re-do things - most changes that stick only tweak 1 variable at a time vs trying to change the whole system. So I would certainly not come in and try to redefine how ideation, scoping, planning, commits, shipping, reviews, etc work on Day 1. But if the team already ideates then I'd try to introduce customer conversations / user research as another avenue to generate ideas, then connect the dots to show that ideas that were grounded in external learning (vs internal opinions) had higher value over time.

The good news is that you have an engineering team that is excited about the product & generating ideas. That’s huge. Over the long term, this will make your product more successful....so long as you can channel that excitement towards features that are also exciting to customers.

Your goal is to help your team fall in love with problems, not solutions. I’ve seen over and over again how this simple mindset shift can be a game changer for more user focused decision making.

Here are some approaches to consider:

1. Expose your team to users - have engineers shadow user research sessions, share clips and quotes, or simply talk about your customers constantly. Bake user feedback into the development process if it isn’t there already. I’ve found that teams get most inspired when we ground their work on real humans. Use this to your advantage.
2. Tweak your process with one pagers & “problem kick offs.” For every non-trivial project you take on, write a simple, one page description of the people problem, hypothesis, success criteria, and “skeleton of a solution.” By skeleton I mean, just enough to start thinking about solutions: e.g. "the ability upload a pin to a board" vs. "an upload button on the profile." Schedule a kick off to discuss and debate the problem, refine your hypothesis, brainstorm potential solutions - even before getting into requirements.
3. Perfect your problem statement. Below are some best practices for writing problem statements. You may even encourage your engineering team to write these for their ideas! Here's what makes for a good problem statement: 

• Is ONE sentence
• Gets as close to the actual human behavior as possible. Avoid sayings like “the industry is changing” or “our systems are disconnected” those are just facts not problems in and of themselves.
• Does not hint at a solution. Example of hinting at a solution: “We don’t have a common place for users to come…”
• Is as specific as possible. Example: “drive efficiency” often isn’t specific enough - what does that mean exactly?
• Is written in plain & simple language. “Project managers don’t have data tracking mechanisms built into their current workflows” => “Project managers don’t know what’s on track and what isn’t”
• Includes WHO it’s a problem for (preferably a human being)
• Is meaningful - describes the impact/negative outcome

One way to get Engineering excited about customer focus is to invite them to listen in on interviews. We post all customer interviews on a shared calendar and use webinar settings that ensure observers hopping on / off are not disruptive to the participant or moderator. We also run an internal back-channel where observers can discuss responses or suggest follow-up questions. Often, I see that hearing directly from individual customers drives a level of engagement for Engineers that is much higher than if they were merely reading a written summary of aggregate responses at the end of a study. 

For Engineers, hopefully that can make more tangible the impact that your products can have on customers' lives and inspire greater empathy for customer challenges.