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
- To show business value in their own engineering work where it’s not easy to articulate
- To empathise better with customers of the software their building
- 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.
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 a "gut feelings" with less certainty than metrics but they're no less valid.
If you're interested in an abstract view on objectivity this 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 then 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 can engineers avoid group think 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 principals of sticky ideas
Chip and Dan Heath wrote a nice book on making ideas sticky. These principals apply to creating and selling your products, features, engineering solutions.
If you ever have to give a technical presentation or sell an idea you should refer back to the principals.
- 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 principals 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 tricker 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 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 chose 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 to learn the basics. They will definitely help you when you’re building a side project!
Top comments (0)