Inspired: How to Create Tech Products Customers Love by Marty Cagan

The book (first published in 2008 and updated in 2018) covers the end-to-end development process for creating great products including variations for different target customers (B2B vs. B2C) and company sizes. I’d recommend the audiobook as the author, Marty Cagan, reads it himself which adds a welcome touch of authentic familiarity to his many entertaining anecdotes.

Cagan is the founder of Silicon Valley Product Group (a product management consultancy) having previously worked as VP Platform and Product at Netscape and Senior VP Product and Design at eBay. If that’s not impressive enough, Cagan is also often referred to as the “most influential person in the product space” – according to productmanagementfestival.com

Here are three takeaways from the book that we’re putting to work at MarketInvoice:

1. Before building anything, validate that the solution is valuable, usable, feasible and viable

This may seem obvious but it’s easy to miss out on validating one or more of these aspects, which massively increases the risk of building the wrong thing.

Value → ‘Do your customers want this as much as you think they do?’ ‘Will they use/buy it?’ Even if they’re asking for it, they might not know how much work it will be and you probably don’t know how much they want it before you ask them.

Usable → ’Can your customers work out how to use it?’ It’s hard to justify building something that your customers won’t be able to use easily. This will likely lead to inbound queries and further work to tweak the feature until it’s useable.

Feasibility → ‘Can we build this to the required standard in the time available?’ Even if you’re sure it can be built, can it really be built to the standard the customer expects in the time you’re allowing? Maybe it’s easy to build a basic version but very hard to get it to the standard they expect. Moreover, some features are time sensitive, in which case the feature taking too long to be implemented could be as good as not delivering it at all. Feasibility is typically the engineers’ domain, who provide scope estimates before kicking off projects. Clearly, the time it takes to build a feature will also influence its viability.

Viability → ‘Will this deliver the business impact required to justify the cost of building it?’ For it to make sense to build a feature, it must a) make more money for the business than it costs to deliver – in terms of people’s paid time – and b) provide a better return on investment than available alternative initiatives.

At MarketInvoice, we take validating solutions seriously. We use a number of methods to validate value including customer surveys and interviews as well as second-hand customer feedback we’ve collected over time. For usability, there’s no substitute for getting designs – wireframes, mock-ups and interactive prototypes – in front of our end users (read more about our approach to design and prototyping in particular here). Viability can be addressed by analysing the downside scenario (number of new customers, additional revenue, time saving etc to breakeven) and the upside scenario (expected return on investment) comparing them to alternative projects.

Cagan has a standalone blog post on the Four Big Risks here.

2. Delivery is overrated, focus on outcomes

Let’s say you look at the data or hear from your internal teams that onboarding new customers is too slow. Maybe you even hear that your biggest competitor can do it 3 times quicker than your company can. You decide this has to change, so you get together with the relevant stakeholders and technical colleagues to define a solution.

The team (you, engineers, designers, stakeholders etc) deliver the solution you identified in week 4. Do you celebrate? No. Customer onboarding time hasn’t moved and is still much longer than your biggest competitor. There is nothing to celebrate. You delivered a project but delivery is only valuable to the extent that it influences outcomes. Focus on outcomes.

One of our key priorities at MarketInvoice for the next six months is to improve and leverage our data infrastructure, making sure the whole company is making the most of data in their decision making. To help us focus on outcomes, we’re making sure we have OKRs (Objectives and Key Results) and the means to measure them in place before kicking off projects. We then monitor them after the agreed scope of the project is complete. If the OKR isn’t hit, we’ll get together and brainstorm options (often taking the form of further development work) to get us there.

3. You’re probably not as agile as you think and you’re probably not making the most of your talented engineering and design colleagues

Many companies that view themselves as employing Agile methodologies are actually only employing Agile delivery. For example:

A. The Product team works with stakeholders to create a product roadmap and spec projects

B. Engineers provide high-level estimates for each project to facilitate the roadmap

C. When it’s time to start a project, the PM asks the Design team (who were not involved in the speccing) for designs, expecting them to reflect what’s in the PM’s head, which had been relayed to the engineer for the purpose of the scope estimate

D. The engineers are then given the spec (written by the PM) and the design (designed by the designer) and is asked to implement

E. The engineers then split the project up into stories or tasks, delivering value in Agile sprints

Cagan covers two issues with this approach. Firstly, A-D are much more reminiscent of a traditional waterfall approach. The roadmap and constituent project spec were likely produced well in advance of the project being picked up and thus they are likely to be ‘stale’, not reflecting new information discovered in the intervening period. Engineers can adapt their approach to delivery as they go but they have much less ability to amend the scope or design of the project as they deliver.

Secondly, his approach underplays the value that engineers and designers can bring to road mapping and product discovery. In addition to providing differing perspectives that could benefit ideation, involving engineers and designers from the start should minimize the risk of discovering blockers (technical / design limitations) down the line. In the words of General George S. Patton, “Never tell people how to do things. Tell them what to do, and they will surprise you with their ingenuity.”

At MarketInvoice, each business area has product, engineering, design and data leads who create the roadmap together. Likewise, prioritised projects have an engineering lead, product lead, design lead and data lead assigned to them (where applicable). The engineer, PM and designer are involved from the start of the project, discovering what to build (if anything) together using data and by talking to internal stakeholders and our customers. After the scope and design have been agreed, the engineering lead project manages delivery with input from the PM and designer where required.

I hope this brief look at Inspired as well as how we put some of its lessons to work at MarketInvoice was useful and that you’ll consider reading or listening to the book! Feel free to get in touch to tell me what you think of the points above, your own highlights from Inspired or other product management books or resources (c.guttridge@marketinvoice.com).