10 Useful product-thinking lessons for engineers

Published on November 27, 2021

This is foundational series article. Read more here

Tagged: #engineering #management

Follow me on twitter for more posts like this

Have you ever struggled to explain the business value of a piece of engineering? Like why a particular piece of tech debt needs to be paid down now?

Engineers can learn from the techniques and rigour that product management practice has created in the past few years to

  1. To show business value in their own engineering work where it’s not easy to articulate
  2. To empathise better with customers of the software their building
  3. To understand the business context you’re in

For example, how can you know that you’re building something useful for your customer? How can you convince others that you’re not ahead of your time with an engineering solution?

For engineers there are some product development lessons that will improve your empathy and communication with non-engineers in your org.

Be able to name and describe specific customers

You might have Personas in your organisation that you use in stories. Personas are designed to represent categories or segments of customer for a product.

Personas can be useful but you have to remember that personas are still manufactured entities. They are artificial.

You and your team should also get to know specific customers that can represent an important segment. Talk to them, write down a profile.

  • Name
  • Age
  • Occupation
  • Brands They Use + Purchase From
  • What Kind Of Language They Use
  • Where They Spend Their Time
  • Their Pain Points
  • What They Hope To Achieve + Accomplish

Your product team or customer support team would be able to help with this. They might already have interview videos and transcripts available.

Understanding where your customers are coming from will help you “get out of the building” and prevent your team looking inward when creatively solving problems. Take the time to get to know specific customers.

Upgrade your customer, not your product

For every ticket you work on you should understand how it helps the customer be better at X or improve their lives.

Some examples of this way of thinking are

  • Don’t build better cameras - build better photographers.
  • Starbucks doesn’t sell coffee, it sells a third place between home and the office.
  • The bank doesn’t sell mutual funds, it sells financial freedom.
  • Apple doesn’t sell computers, it sells tools to unleash human potential.
  • In the factory we make cosmetics, in the drugstore we sell hope. – Charles Revson.

As an engineer you don’t have to directly help customers all the time but you should be able to frame every piece of work in terms of improving your customer. If you want to improve some part of architecture you should be able to describe how it will remove friction in the user experience.

Use metrics but with a balance

There is a tendency for quantitative approaches in engineering. We love to measure specific systems and respond. But the products you build are usually used by other people. People are interesting and don’t conform to the behaviours you might expect from analysing numbers.

Qualitative data comes from interviews, observation and research where the data is filtered through the experiences of the user. User experience designers and product managers often run these kinds of research scenarios but if you have the opportunity to join one in your organisation you should!

As an engineer you might not be gathering this type of data. You do need to interpret and respect the results. The software product you’re building exists in a dynamic system with people in it and that makes it extremely difficult to measure. Decisions that come from qualitative research can be more like “gut feelings” with less certainty than metrics but they’re no less valid.

If you’re interested in an abstract view on objectivity you should check out Roger Scruton’s nice documentary on “Why Beauty Matters?” - https://vimeo.com/128428182.

Tools for opportunity cost

There is never enough time or people to build everything you want to build. Typically a product manager will prioritise work. You need to understand that while you’re spending time building one thing, there is a cost to not building some other thing. This is called opportunity cost.

Prioritisation is a vital skill for every engineer to learn so you can work on the most important tasks when you don’t have a product manager to help you out. I have written about some techniques I use to prioritise here.

Moving faster in engineering is one way you can reduce opportunity cost for your organisation. If you can finish one thing faster, you can get started on the next thing sooner.

There is a balance required here with another great tool to reduce opportunity cost - quality. If you keep quality high and reduce regressions you should only ever be adding value to the product. Working on regressions is a terrible loss of opportunity to make your product better. Keep quality high while moving fast.

Before you even write any code there is a neat process tool called the Lean Canvas that is used to analyse the value of potential problems and solutions.

The lean canvas is a structured way to work through a business idea (or any valuable initiative).

It’s a one-page business plan. There is an example template with detailed instructions available here or if that link is broken just search Google for “lean canvas template”.

Engineers can use lean canvas to help describe the value for a piece of work just like a product manager would. It can be difficult to think this way initially so don’t give up if you struggle the first time.

Using a structured thinking tool like lean canvas, engineers can avoid groupthink by having each member of a team, or sub-teams do their own lean canvas and then combine the results afterwards into something the whole group thinks is valuable.

Rapid experimentation and the scientific method

It’s important to keep a record of engineering experiments like brainstorming or proof of concepts and log any results so that you don’t repeat yourself.

There’s another nice template for this from the folks at “Moves the Needle” called the Rapid Experiment Map. You can find the template here.

The idea here is that one experiment should provide actionable feedback to the next experiment. It’s essentially describing the scientific method.

An engineering focused experiment is just as applicable to this kind of rigour as product experiments. You should have a system in place like this to capture results of engineering experimentation.

Understand there is an ecosystem

Even if you have a single product you are in an ecosystem. Engineers should understand the wider ecosystem that you’re building in.

  • Who are you and your customers’s competitors, suppliers and customers
  • What are the strategic forces or trends driving change in the industry e.g. international developments, government regulations
  • Your customer’s own company - its organisational structure, marketing, operations, information - technology and finance, which surround your particular expertise
  • Are there any adjacent or parallel industries

The principles of sticky ideas

Chip and Dan Heath wrote a nice book on making ideas sticky. These principles apply to creating and selling your products, features and engineering solutions.

If you ever have to give a technical presentation or sell an idea you should refer back to the principles.

  • Simplicity - Strip your idea back to the core
  • unexpectedness - Grab people’s attention with the unexpected, go against the status quo
  • concreteness - People remember what affects the senses. Abstract words, concepts and ideas should be framed in a concrete way
  • credibility - People respect authority, you have to generate it if you don’t already have it
  • emotions - People remember ideas that impacted them emotionally
  • stories - A good story can last thousands of years. Tell stories to have people remember your idea

The principles make a handy backronym “SUCCES”.

Use the HEART framework to measure and improve user experience

Most of the time you have easy ways to measure engineering specific dimensions. You measure metrics like throughput or resource usage for all of our systems. You can use these metrics to monitor the health and success of our solutions.

In product development you need to measure how you’re doing. This is a bit trickier to measure but Google researchers have published their “HEART” framework for measuring user experience success and it’s good to know about it so you can apply it to complex engineering problems where there might not be a single easy metric available.

Not all of the HEART metrics will apply to every product or feature you build and it’s important to measure change over time rather than a single point measurement.

  • Happiness: This is a measure of customer satisfaction.
  • Engagement: How often the customer chooses to use your feature.
  • Adoption: New customers using your product
  • Retention: How long those new customers stick around
  • Task success: How useful is your product to the customer

For each HEART metric you should set a goal. You can choose the top two or three goals to focus on.

Now you can identify the signals that apply to measuring that goal is achieved.

Finally list some specific measurable metrics from the signal.

This creation of goals can help you compare features before you build them. If you’re tracking features that are already in your product then the HEART framework can show you if you’re improving over time.

Get comfortable with pivoting

If you’re measuring the success of your product and it’s not working then you might have gotten it wrong. This is OK in the product world. You try an approach and move on if it doesn’t work!

In engineering you have to get comfortable with these kinds of changes. You might spend 3-6 months engineering a feature only to find that no one uses it and you need to scrap it and build something different.

The lean startup book by Eric Reis has a nice summary of the different types of pivots

  • Zoom in pivot
  • Zoom out pivot
  • Customer segment pivot
  • Customer need pivot
  • Platform pivot
  • Business architecture pivot
  • Value capture pivot
  • Engine of growth pivot
  • Channel pivot
  • Technology pivot

Work with the product manager to understand their reasoning behind the pivot so you can retire the old approach and create the new approach in the best way possible.

Intercom on product management

Intercom is a very successful Saas product and they are well known for their product management practice blog called “Inside Intercom”.

They released a book a couple of years ago that provides solid practical tips on building great products. It’s a very dense book with huge value for engineers. You should take a look if you get a free afternoon - https://www.intercom.com/resources/books/intercom-product-management

The topics covered include analysing your existing product, picking the right features to build and how to get users interested in using a product or feature.

One of my favourite points in there is

“Telling your customers something is a “ground up rewrite”, “HTML5 based”, “responsive” or anything like that will miss the mark unless you’re selling to developers.

No one cares what you did, or often even how you did it. Your customers care about what they can do.”

Building great (enterprise) software

Enterprise software is usually sold to a purchaser that is not the final end-user. A VP or similar will compare feature lists and pricing and choose a solution based on that. This process results in incentives for your enterprise software company to appeal to this purchaser rather than the end user.

You get complex software with enormous flexibility to appeal to VPs and feature lists as long as possible to make the software stand out against competitors. You can learn some product ways to get better software to the end users of enterprise software.

Ilya Fushman at Kleiner Perkins put together a fantastic summarized list of how to excel in the enterprise software market.

  • Build Amazing Consumer-Grade Product
  • Leverage Virality Across Individual Users To Grow
  • Personal + Professional Adoption @ Low Cost
  • Harvest Individual Users for Enterprise Go-to-Market With
  • Dedicated Product + Inside / Outbound Sales
  • Build Enterprise-Grade Platform + Ecosystem

Most of these points apply to any product if you just remove “enterprise”.

Build great products that customers will rave about. You must market it. Make it easy for customers to get started. Build a platform to make it harder for them to leave.

Enterprise software is massively complex and difficult to get right. The software has to appeal to the purchaser instead of the actual user. As an engineer, try to bring some love for the end-user back into the software you’re building.

Surprising Pricing

Studying pricing is interesting because you often undervalue your work as an engineer. Your customers are willing to pay significant compensation to quickly solve problems.

Pricing is one way to measure how horrible a problem actually is for your customers. For example if you have to pay your customers to use your product instead of them paying you then maybe you’re not solving a real pain.

These are some pricing suggestions from patio11’s blog for smaller side-projects that an engineer might do. Some of the consulting prices surprised me when I first saw them but for someone who needs a problem solved quickly they’re not really significant for most organisations with more than 1 person.

  • A book - $50
  • Video course - 497
  • Saas plan - $100s/month
  • Mid-tier Saas - 2.2x
  • High-tier Saas- 5x
  • Specialised Consulting - $30,000 / week
  • Personalised advice with 10 people (batched webinar) - $997
  • Mini consultation (and private skype chat) $2500

When you’re talking about B2B SaaS products the price is at least thousands per month. Enterprise deals are in the millions. It’s important to understand the value of the product you’re making.

Summary

There are some great product development practices that engineers can learn to improve their capabilities. They will help you emphasise the value of engineering work to all stakeholders on a project and they will help you to empathise with your customers.

The practices might even prevent you from over-engineering something if you realise that you can’t articulate the value of some work!

You should spend some time learning the basics. They will definitely help you when you’re building a side project!

References

Darragh ORiordan

Hi! I'm Darragh ORiordan.

I live and work in Sydney, Australia enjoying the mountains and the ocean.

I build and support happy teams that create high quality software for the web.

Contact me on Twitter!


Read more articles like this one...

List of article summaries

#developer-experience

How engineers can help deliver software effectively

Delivery managers and team leads have the responsibility to deliver a software system via an engineering team.

Your customer wants every feature to work perfectly and they want it delivered yesterday. Your team wants to learn and grow.

It’s a tough role managing all the stakeholders and creators in a project.

Engineers can help drive great delivery by empathising with and supporting the delivery manager or leads in a project team.

#engineering

Engineering systems for consistency and impact

Your most impactful engineering is done before you write any code.

It’s important to have some systems around how you approach problems to make sure you’re consistent every time.

These are some of the techniques I use to make sure I’m covering as many angles as possible when doing my pre-coding engineering.

#engineering

How software engineers can avoid commoditisation

Engineers spend most of their learning time on technical implementation content. Things like new frameworks, languages or cloud platforms.

But turning solutions into code is a tiny part of what you do and it’s getting less valuable year by year.

As we’ve seen with “no-code” and tools like GitHub Copilot, the implementation part of our role is increasingly becoming commoditised.

You could generalise that the value an engineer brings to a team is their ability to analyse problems and synthesise context. The part of your role as an engineer that will never be replaced by “no-code” or AI is this high level cognition.

The true human aspect of being an engineer is working in a team and considering other people’s ideas, emotions and thoughts while solving these problems.

So shouldn’t you train these meta-cognition skills as much as you train the specific technologies?

Every engineer should spend time learning and applying general tools for thinking. These tools are applicable to almost all problems so the compounded payback on your invested time is huge.

Clearer thinking will amplify all the other skills you have and any frameworks or tools you learn will give you results for the rest of your career.

Like any skill, improving the way you think takes deliberate study and practice.

These are some of the tools and systems for thinking that I refer back to all the time.

#engineering

20 questions for a valuable code review

I recently had an interesting discussion around the value of doing code reviews and the value of mandatory code reviews.

I think code reviews are extremely valuable and should be done by most organisations and teams.

A valuable code review will

  • pass institutional knowledge around the org
  • help all engineers grow their skills
  • maintain quality in the face of all the other time pressures your team faces

But how do you keep a code review valuable?