A Guide to Create Tech Products — Part 1 Lessons and Key Concepts

Photo by Marvin Meyer on Unsplash

Not so long ago I came across one book about product management that really opened my eyes on how things should operate inside companies or startups in the creation of tech products. This book is called INSPIRED How to Create Tech Products Customers Love, by Marty Cagan. I am currently a software engineer with good interest in the business side of problems and follower of trending tech products in general. I would recommend this book to anyone who is Product Manager, Product Owner or even a Software Engineer for the sake of knowing what flaws are present in your own processes of product creation or learn a pragmatic way in which you could help your team. Maybe you could bring something new to the table. If that is the case leave a clap for the favor.

It is my strong belief, and the central concept driving this book, that behind every great product there is someone — usually someone behind the scenes, working tirelessly — who led the product team to combine technology and design to solve real customer problems in a way that met the needs of the business. Marty Cagan

(Disclaimer) The order of the chapters have a little twist from the original book, in my opinion this is a better top-down approach for understanding the basics. Nevertheless I hope you enjoy the reading!

Key Concepts

It’s crucial for anyone working in tech to learn certain words or expressions just for the sake of communicating effectively with peers, but also understand what you need to take into consideration for a successful product.

Holistic Product

According to the author an holistic view of a product consist on considering all the different views that should integrate a product as a whole and these include the following aspects to consider

• Functionalities of the features
• Technology that enables the features
• User Experience Design that presents the functionalities
• Monetize this functionalities
• Acquire Users and Customers and how to attract them to use our product
• Offline Experiences

Product Discovery

The output of the product discovery phase is a validated product backlog. This basically means responding 4 critical questions:

• Will the user buy this?
• Can the user figure out how to use this?
• Can our engineers build this?
• Can our stakeholders support this?

This process is aiming to detect and reduce the potential risks that come in the product development making sure it is a continuum of improvements, iterations and validations with users.

Prototypes

Product Discovery involves doing a series of very quick experiments and to do these experiments quickly and inexpensively, we use prototypes rather than products.

To set expectations, strong teams test many ideas each week — on the order of 10–20 experiments or more per week. Marty Cagan

A prototype is not something ready for production use and certainly not something your company should sell and make there foundations in.

Product Delivery

This means the necessary scale, performance, reliability, fault tolerance, security, privacy, internationalization, and localization have been performed, and the product works as advertised.

The purpose of product delivery is to build and deliver these production-quality products, something you can sell and run a business on.

Products/Market Fit

Just because we’ve invested the time and effort to create a robust product does not mean anyone will want to buy it. So, in the product world, we strive to achieve product/market fit.

This is the smallest possible actual product that meets the needs of a specific market of customers.

Products need a whole lot after their creation and delivery, with marketing, customer acquiring, and scaling being one of the top priorities past this initial phase

Product Vision

The final critical concept is product vision. This refers to the longer-term objective of this product, normally 2–10 years out. It is how product teams intend to deliver on behalf of the company’s mission.

Synthesizing…

We use prototypes to conduct rapid experiments in product discovery, and then in delivery, we build and release products in hopes of achieving product/market fit, which is a key step on the way to delivering on the company’s product vision.

In my experience as a software engineer aspects such as “how to acquire customers and attract them to use our product” or “can the user figure out how to use this” are omitted for the development team and almost always there is another department in charge of making this happen, being it sales or UX team for example, instead, this should be a collaborative job in which business strategy or design decisions are displayed and discussed publicly with the teams.

Also prototyping is a must do for startups to begin their journey in the market and is a necessity for us engineers to establish easy solutions to complex problems in order to start building from there. A classical example is to start building a microservice architecture for something that is not tested yet and could be easily developed as a monolith.

For the product vision IMHO in latin america there are few organization that really have a product vision and strategy for the medium term being 3–5 years. Most of the tech startups and enterprises just focus on the daily basis operation and visualize only 1–2 year ahead being little to none the ones that really have a product strategy for the upcoming years and also have a strategy to deal with competitors in this fast phase environment.

Why Products Fail

In the book Marty Cagan writes about 10 factors that contribute in product failure

1. Sales and Stakeholders dictate the phase of ideas

When people from sales or stakeholders who don’t interact on a daily base with the customers nor the product teams make decisions or bring ideas to the table they are probably wrong on their approach. It’s pretty common in some small startups where the sales team dictate the phase of features that go into the market based on the competition or their own KPI’s.

Another pretty common issue in bigger companies where the CEO dictates the ideas (CEO pet feature) or stakeholders of the directory bring ideas, for example of the competition and all this cascades down to the product teams, and teams start developing features that don’t necessarily are a key factor to the organization strategy.

Both of this problems make teams lack of empowerment and then stop being autonomous in deciding how and when things should be done, instead they start behaving as a team of mercenaries rather than creators, in which by default makes them less valuable to the company

2. Business cases trying to predict the unpredictable

When trying to build a business case to dictate the income and costs of the product is just playing a game of estimates. The cold truth is that at this stage nobody knows anything about this two, in fact, we can’t know.

This truth radicates on the estimation that all this income comes if the product is successful and loved by the users, thing that is flawed as many products will probably end up generating absolutely nothing.

Likewise we have no idea of how much it will cost to build. Without knowing the actual solution it becomes really hard for engineers to predict or even give an estimate about how much it will cost in time and money. Although, many engineers are forced to give an estimate in the old fashioned way of t-shirt sizing compromise “small, medium, large or extra large”.

Companies really like and want their prioritized product roadmaps, and to get one, they need a system to rate ideas. So people play the business case game.

3. Companies get too excited about their product roadmaps

There are 2 inconvenient truths about product.

1. At least half of our ideas are just not going to work
2. Even tho we got ideas that do prove to have potential, these take several iterations to get the right implementations where it delivers business value. Time to money takes too long to come around with the expected results

4. Project management v/s product management

While some enterprises will hire “product managers” these are classical project management roles where gathering requirements and documenting them is the norm, which is 180 degrees of what is supposed to be done by product management.

Product management is much more than just gathering and documenting requirements, it’s understanding the product, the customer, the technology, define the strategy of the product, how will it scale, understand the market, competition, the UX and much more.

5. UX role is too late

UX most of the time comes late into the game and what it is really trying to solve is putting a good cover for something that is being bad designed for users since the beginning (“lipstick on the pig”)

6. Getting half value of your team

If you are just using your engineers to code, you are just getting half the value that you could achieve. The little secret is that engineers are typically a great source of innovation, yet they are not even invited to the party in this classic process.

7. Anything but Agile

What we really see is agile for delivery, but the rest of the organization and context is anything but agile. We are just getting about a 20% of the value that agile principles and key benefits bring into the process.

While almost everyone today claims to be Agile, what I’ve just described is very much a waterfall process. Marty Cagan

8. Output vs Outcome

Most of the time companies fund projects, staff projects, push projects through the organization and finally launches projects. Unfortunately, projects are all about output and product is all about outcome. This approach always leave orphaned projects or don’t leave enough room for people to innovate around ideas because of the lack of output that this could bring to the company and the less “value” they could be generating

9. Customer validation comes too late

All the risk comes at the end, yet customer validations also comes too late when it should be done during the whole process, specially at the beginning.

The key principles in LEAN is to reduce waste in the process and one of the biggest waste is to design, build, deploy a product only to find at the end that the product was not needed. The irony comes that many companies think they are applying LEAN principles, yet they follow the wrong approach mentioned before. This is one of the most expensive and slowest way to build a product.

10. Opportunity Cost

The biggest cost companies incur when doing the old process of product design is the opportunity cost of what they could and should have done instead.

It’s no surprise that so many companies spend so much time and money and get so little in return.

Marty Cagan

From my perspective of a software engineer I have experience first hand certain points from above.

In first place, project management vs product management is a classical error in organizations. This leads to a problem when communicating with the development team, wrong roadmap prioritization, unreachable timeframes and flawed product strategies, if we add to the receipt the methodologies like gantt charts, it leads to an “anemic” agile in which everything is waterfall but we claim to be “agile”… leading to point seven.

Secondly, the role of UX and validating with users usually comes way to late in the picture. Many products tend to be developed entirely before going to test with the end users. Being an internal tool or client facing web app or mobile app, it’s a classical error for product owners and product managers to avoid testing until the “necessary sprints are done” also leaving behind the input from engineers when testing is done. I really encourage a ritual “on the shoes day” in which engineers, product owners and designers live (suffer) for a day as an end user using the product.

Finally, the point of being a mercenary rather than a creator is something some business suffer, especially big non-tech companies, where developers are more of a commodity rather than a valuable member of the organization whose input is valuable for the business.

Beyond Lean and Agile

The process of product discovery and delivery goes sometimes beyond the classic views, for example, lean or agile . Instead the author propose 3 overarching principles to dictate how work should be done

Risk are tackled up front, rather than at the end.

All products and projects include risks. This risks in the case of tech products can be classified as 4 and these should be addressed as early as possible before resources are lost building something not worth the time and money. It’s the role of the product manager to ensure the following risks are taken into consideration and make a deep diagnosis of them.

a. Value: Whether or not the customers will buy the product

b. Usability: If users will figure it out how to use it

c. Feasibility: Whether the engineers can build what we need with the skills, time and technology we have

d. Business Viability: Whether this solutions works for the various aspects of our business — Sales, Finance, Marketing, Legal, etc

Products are designed collaboratively rather than sequentially

Teams should not follow the classic process of project management where Product Manager defines the requirements, the designer designs a solutions that delivers those requirements and the engineering team implement those requirements, everyone living within the constraints and decisions of the ones that preceded. Instead Product Manager, designers and engineers should work side by side in a give-and-take way to come up with a technology powered solution that customers love and works for the business

It’s all about solving the right problem not implementing features

It’s not about the output, quantity of feature or projects. Strong teams knows that is not about implementing a solutions. It must solve an underlying problem. It’s all about the business results. Teams need to love the problem, understand it and spend a significant amount of their time knowing what and why are they solving it.

Unfortunately, projects are output and product is all about outcome.

Marty Cagan

From my perspective various projects are focused on outputs (projects) and not outcomes. These are strongly influenced through the organization and not necessarily have a strong argument behind for example of Business Viability, Usability for users being them consumers or internal users nor correct business problem definition with use cases and forecasts of the value added for the company.

Through time, product owners end up being a ticket master for bugs, small improvements and operational continuity lacking the faculty to solve the real problems no one else is addressing.

Finally, there's a whole lot to learn about product discovery, team building and delivery of tech products. Many exponents of the industry are leaving their knowledge on books, TED talks, podcasts and articles over the internet that everyone should be looking for. It is a never ending responsibility for anyone from the stakeholders, product managers, product owners, scrum masters, software engineers to designers to learn about this process and bring new ideas to the table.

This is intended to be a series of 4–5 articles resuming this spectacular book and leaving insights of my little experience working in software development. Hope everyone likes it.

Thanks for reading!