Download the PDF at productengineer.org
How to Think Like a Product Engineer
The following is a checklist of questions for product engineers:
1 Understand
1.1 Who's the user?
As a product engineer, your #1 goal is to create happy users. These are your fans! Always start with the user!
Your user is the person that primarily interacts with your product and whose experience your work will directly impact.
You may have multiple user groups. People who may have varying reasons to use your product or might interact with it in different ways from different angles, maybe on different kinds of devices.
You should understand how to help these users. What drives them to use your product? What delights them? What are their pains?
As a product engineer you should demand and support your team find answers to these questions before jumping into writing code.
1.2 Who's the customer?
Yes, this is a different question to "Who’s the user?". The customer is whoever pays for your product, not always who uses it.
You should know what makes your product valuable to your customers to make better decisions on what to invest your time.
Hint: If you're in B2B the answer always has to do with helping your customers save money or make more money. Understanding your customers' core business is key to understanding why they would pay for your product.
Most importantly, you want to make whoever is paying for your product look good. After all, they're the ones taking a risk by picking your product. You ALWAYS want to reward them for that.
1.3 What's the market?
Zooming out, let's take a look at the wider market landscape. Who are the potential customers we haven’t captured yet? Why would a customer pick a competitor’s product vs. mine? Are we leaving opportunities on the table?
What can I learn from similar products in the market? What are our USPs? How do I create a competitive advantage against competition?
Are there rules to the market? Are there regulations or industry standards I need to know about? Does my product have to look or feel a certain way to be taken seriously?
Knowing the market and regularly bechmarking yourself against other players helps become aware of your strengths and weaknesses and give ideas for where to invest strategically in your own product.
1.4 Ask Why
This is a bit of a product thinking cliche but still holds true: always pays to ask “why” a few times to uncover root causes of problems and underlying motivations.
Asking why can be helpful in almost any situation to build understanding in your team. Some examples:
- Why should we invest into building this feature?
- Why are customers asking for this feature?
- Why is this a pain for our users?
- Why do users give us that feedback?
- Why now?
1.5 What do we already know?
It’s smart to build on what’s already known rather than always starting from scratch.
Always leverage the existing knowledge and experience of peers and leaders: founders, product leadership, designers, other product engineers, etc.
Examine the status quo to see how a problem is currently solved. Look at ideas, feedback, metrics, KPIs already collected in the past.
Do we have users already doing something like this? What are their existing workflows? How could we improve their experience?
Am I duplicating or potentially deprecating some functionality that already exists? Could this be achieved by extending or leveraging existing features? How are competitors solving this?
2 Craft
2.1 Am I proud of what I'm building?
Your track record as a product engineer is the products and features you've delivered. Your last feature represents your professional competence level. No excuses.
Ask yourself what quality standard do I want to set for the work I put out there?
Can I be proud of the product I worked on? Is my work well tested and polished? Did I cut corners where I shouldn't have?
As a highly paid professional engineer your craft is to produce high quality software which includes avoiding the creation of technical debt. Never ask for permission to improve quality!
What makes a great product engineer stand out from the average software engineer is an intense sense of professional pride in their work and product.
2.2 Does the product feel good?
This may be a slightly controversial take, but I believe a surprisingly large part of building great products is about developing a good taste for it.
Simply knowing the difference between great vs. average and not settling for just ”ok” helps tremendously in making good decisions as a product engineer.
Does the product feel smooth and consistent? Is it intuitive, simple, and familiar to the user? Or does it feel cheap and janky?
Note that this doesn’t only concern the visual aspects of your product. Just slapping a fancy UI design on a shaky foundation doesn’t create a great experience.
Simple. Elegant. Clean. This is what we're after as product engineers.
2.3 How do I get there faster?
The pace of innovation especially in software is so rapid that in order to be competitive you must deliver fast, early and often.
Too slow and your customers will lose trust in you while your competitors overtake you.
What many get wrong about agile and building products is optimizing for predictability with estimates and roadmaps. Rather, what you really should care about is visible and continuous progress towards product goals.
The goal of estimates should not be to try to be as accurate as possible but rather to set ambitious and yet achievable goals for yourself.
The question is not how long you think it will take to build, but how long should it take? What’s an acceptable amount of time and effort I should invest on this?
What’s the rollout strategy? How do I get this into customers' hands as soon as possible? What’s the MVP?
2.4 Teamwork
Building products is a team sport.
You are absolutely not expected to work alone and do everything yourself from writing code to doing user research.
Am I effectively communicating with my team? Am I leveraging my team members' strengths? Are we celebrating our successes?
Great teamwork results in great products. Invest in your team, and you will see the dividends in your product's success.
3 Growth
3.1 How do I measure the success of my work?
Our work as product engineers is not just about building and shipping feature after feature.
We make educated guesses about the most valuable thing to work on, so we should also be able to answer the question: What’s the impact of my work?
How many customers did we talk to to validate our progress? Are they coming back? How much money does it generate?
Use analytics tools and user feedback to help you understand what’s working and what’s not. Talk to real users to get qualitative insights about the product.
Most importantly, make sure to share your outcomes openly and transparently. What did I ship in the last few months? What were the results?
3.2 How do I maximise the impact of my work?
The most important question you should regularly ask yourself is: am I focused on the right thing?
Being a good engineer is finding the biggest bottlenecks that hold us back and figuring out how to solve them. You should prioritise your efforts ruthlessly.
Building products is a team sport. You should actively communicate what you’re working on and why, so that others can help you and keep you accountable. Demo progress frequently and actively seek feedback.
Don’t fear taking risks. Being bold and taking the lead on delivering new and innovative features you believe in can lead to big wins.
Ask yourself: How can I align my work with our company goals? How does my work directly benefit our users? Is there a way I can communicate my work better to others to get better feedback?
3.3 How do I stay ahead of the curve?
Stay updated on market trends. Attend conferences, read up, follow experts.
Make sure to research and benchmark competitor products, or other similar products whenever possible.
Hold frequent retrospectives and brainstorming sessions. Experiment with new ideas. Encourage creativity in your team.
What are the latest trends in my industry? How can I encourage innovation within my team? Are we taking enough time to learn from our successes & failures?
4 Product Vision
4.1 What’s our North Star?
To align your work in the context of the broader product vision, you should deeply care about what others in the company are doing and saying, making sure you fully understand and are committed to the overall product strategy. Asking “why” is crucial here.
What are our current product goals? What’s our growth strategy? Where do we want to be in the next 2-5 years?
When presenting your work it always helps to put it in the context of how it pushes us forward in the big picture. How does my work help us reach our North Star?
4.2 How does my work impact the overall design of the product?
Understanding the existing software’s design and architecture decisions helps make sure that your work fits well within the larger product design. Always consider how your work influences and is influenced by other components.
When adding new functionality, you should ask:
- Could this be achieved by extending or leveraging existing core features?
- Does my design follow a consistent style to the rest of the product?
- Am I adding complexity or reducing it?
Simplicity is worth fighting for.
4.3 What's the ambition level?
It’s a good idea to define the ambition level when setting off to build something new. Are you aiming for an incremental improvement or a revolutionary new functionality?
Is this feature a USP or a basic expectation? What’s the ROI on building this feature? Does it make sense to spend the effort building this ourselves, or could we use an off the shelf library or service?
Your time is extremely valuable. Think like an owner: Would you invest your salary to build the feature, or rather on something else?
Product Engineer Mindset
If you enjoyed this checklist, you might also like the Product Engineer Manifesto on GitHub.
Consider giving the repository a star if the Product Engineering philosophy resonates with you!
Top comments (5)
Hello Viljami Kuosmanen,
thanks for the article.
It's easy to read and easy to understand and I think the questions are so well defined that you can follow them to get good answers.
There is only one disadvantage that makes me hesitate. The questions are related to design, coding and management. Following these areas makes the product engineer more than a full-stack developer. Personally, I'm completely against being some kind of full stack developer unless I don't have to excel at everything and can decide when to work on what and how much.
The reason for this is physical and mental health. In theory, a product engineer sounds great, but it seems that a product engineer is someone who has a very poor work-life balance.
Thanks for the comment! Your concern is totally understandable.
The product engineer role is indeed even broader than most full-stack developer roles usually still limited to technical responsibilities only. The key difference being that product engineers are expected to take an active role in product decisions which requires a good understanding of the user, customers, and the overall product vision.
Just reading this checklist it sure sounds like a lot, and to be fair product engineer is a demanding senior role that not all developers necessarily want to grow into. That's totally fine too! There's plenty of demand for technical specialist roles where these skills aren't required.
But being a product engineer does not mean you need to sacrifice work-life balance or your mental health.
As I point out in the article, building products is a team sport.
You are absolutely not expected to work alone and do everything yourself from writing code to doing user research. Product engineers should be teamed up with smart designers, product managers, data analysts and others who will help you answer these questions.
Where a traditional developer might just be assigned a task to implement a feature someone else decided to build, a product engineer is actively involved with their team deciding what features to build and how to prioritise them. They're usually very motivated to build because they know exactly why the work is important and have a lot of influence on the outcomes.
EDIT: I've added section 2.4 Teamwork to make this even clearer. Thanks again for the valuable feedback! :)
"Who's the customer? Yes, this is a different question to "Who’s the user?". The customer is whoever pays for your product, not always who uses it." That is really really deep and I never thought it that way...thank you for the new insight :)
great reading!
Great read @anttiviljami! Now can you please pass me the checklist on where to find those product engineers? :D :P For everyone who checks-off the list: reach out to us, you are wanted!