The making of a Product Engineer

The making of a Product Engineer

When I started as a software engineer I thought it was a case of waiting for the product manager to tell you what to make, the designer then hands you a design file and you work out how to turn it into reality. Fast forward seven years and now it couldn’t be more opposite. Working as a Product Engineer has changed how I see product development and how I think you can make it a more effective lifecycle.

The following post contains my thoughts on how to approach being a Product Engineer, and just how different it can be from being a Software Engineer.


How can I come up with a new idea?

Just stop for a moment. Look at the product you are working on and play around with it. Try to keep one eye on the feedback that comes in. Find the issues and gaps and remember that nothing is too small.

Once you have found your idea, go away and make a proof of concept. It doesn’t have to look good, it doesn’t even have to really work. But what it does need to do is convey the idea clearly to the rest of your team. You want to sell them on why the team should be working on the problem area you have found.

If people seem to be keen on the concept, take it further by writing up a small document on what the idea could be, both short and long-term. It's also good to cover how it could be approached from a technical standpoint. This will help the team see your vision, and also judge if they think it could be worth the expected time.

Question everyone and everything

Product managers and designers will always have valuable ideas and insights, but this doesn’t mean you have to take everything they bring to the table as gospel. Question them on where things have come from, how they see ideas fitting in the current product, and what the longevity is for the feature. A good PM/designer will always be spurred on by this conversation and it can lead to the team pursuing really clear-cut solutions that are likely to have a bigger impact.

We always come to regret our choices

One thing I have seen a lot of new product engineers find difficult is letting go of purist code, it's a hard balance to strike. However, the idea behind being a product engineer is to find out how you can improve a user's experience, and spending months perfecting the implementation of a feature won’t get you there. You have to be willing to write some “messy” code, knowing that the feature will either be scrapped or if it is going to be built on, that you have left yourself in a good place to build from.

N.B. When I say messy code, it’s more about not thinking about scaling or considering covering everything in tests, etc. It's not giving you an excuse to write bad code...

But... I can't design

There is a common misconception that being a Product Engineer means you need to be a designer or have a real love of front-end development. But this is simply not true. I am a shocking designer, and I’ve worked with plenty of backend-focused developers who still make amazing Product Engineers, they just see things through a different lens. It’s more about caring that users have a fulfilling experience than just making the product look pretty.

But how do you deliver it?

You often hear the terms "break it down" and "what is the smallest MVP we can get", but that can be misconstrued easily. An MVP does not mean that the UI is unfinished, or that the experience is a bit clunky. It should mean you’re shipping something useful to the user that can later be expanded on to deliver even more value. There would be no point in me being able to link my Figma account to my Notion account if I wasn’t then able to show my Figma files in a Notion document…

I love to use the cheesy phrase "it's not the minimum viable product it's the minimum valuable product" to get this point across.

How do I know if people actually like it?

This is never an easy one, and I don’t think there is just one way to do it. Data is important; tracking how users interact with your product and seeing where they drop off can help. But quite often that doesn’t tell the full story. Have some way for your users to reach out to you. Be that feedback forms that are accessible in your product, or having a Slack/Discord community where you openly encourage people to give you feedback and ask questions. Speaking to users directly opens so many doors, and stops you from being blinded by your own perspective of how to use the product.


The key point I have taken away from being a product engineer is that there is so much more to look at beyond the code. Take time to play around with the product you are building and explore the different options. Reflect on how customers use it and what issues they face. Push your own boundaries and it will make working as a product team so much easier.