23,99 €
Mehr erfahren.
- Herausgeber: Packt Publishing
- Kategorie: Fachliteratur
- Sprache: Englisch
Lean Product Management is about finding the smartest way to build an Impact Driven Product that can deliver value to customers and meet business outcomes when operating under internal and external constraints. Author, Mangalam Nandakumar, is a product management expert, with over 17 years of experience in the field.
Businesses today are competing to innovate. Cost is no longer the constraint, execution is. It is essential for any business to harness whatever competitive advantage they can, and it is absolutely vital to deliver the best customer experience possible. The opportunities for creating impact are there, but product managers have to improvise on their strategy every day in order to capitalize on them. This is the Agile battleground, where you need to stay Lean and be able to respond to abstract feedback from an ever shifting market. This is where Lean Product Management will help you thrive.
Lean Product Management is an essential guide for product managers, and to anyone embarking on a new product development. Mangalam Nandakumar will help you to align your product strategy with business outcomes and customer impact. She introduces the concept of investing in Key Business Outcomes as part of the product strategy in order to provide an objective metric about which product idea and strategy to pursue. You will learn how to create impactful end-to-end product experiences by engaging stakeholders and reacting to external feedback.
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 334
Veröffentlichungsjahr: 2018
Ähnliche
Table of Contents
Lean Product Management
Lean Product Management
Copyright © 2018 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
Acquisition Editors: Ben Renow-Clarke, Suresh Jain
Project Editor: Radhika Atitkar
Technical Editor: Nidhisha Shetty
Proofreader: Tom Jacob
Indexer: Rekha Nair
Graphics: Sandip Tadge
Production Coordinator: Sandip Tadge
First published: May 2018
Production reference: 1300518
Published by Packt Publishing Ltd.
Livery Place
35 Livery Street
Birmingham B3 2PB, UK.
ISBN 978-1-78883-117-8
www.packtpub.com
PacktPub.com
Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at www.PacktPub.com and as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at [email protected] for more details.
At www.PacktPub.com, you can also read a collection of free technical articles, sign up for a range of free newsletters, and receive exclusive discounts and offers on Packt books and eBooks.
Contributors
About the author
Mangalam Nandakumar has over 17 years of experience in product management and software delivery. She is an entrepreneur and has founded two start-ups. She has worked at Citigroup, Ocwen Financial Solutions, ThoughtWorks Technologies, and RangDe.Org. Mangalam presents a vibrant perspective on product management from her diverse experience of working with start-ups, enterprises, and nonprofits, both in product companies and software consultancy organizations. She has a strong foundation in Agile and Lean methodologies. She has also coached teams on their Agile transformation journeys.
Mangalam started her career as a programmer and soon transitioned to business analysis and product management. She has consulted for businesses in various functional domains and has helped them articulate their product vision, strategy, and roadmap. She has led many software teams through successful product deliveries. Mangalam cofounded her start-up, AIDAIO in 2014, to enable businesses to enhance their customer engagement strategies. AIDAIO was shortlisted under the Top 10 Promising Start-Ups by CII in 2015. Moreover, AIDAIO’s innovative platform to design, build, and launch white-labeled native iOS and Android apps for events and conference was a finalist in the Best Event Technology category at MICE Asia Pacific, 2015.
Mangalam has also spoken at various conferences on topics related to Agile and product management. She started her writing journey by blogging on topics related to product management, team processes, and diversity at workplaces. She is passionate about mentoring women and is a vocal advocate for diversity at workplaces. She was instrumental in founding organization-level initiatives to coach and guide women to speak at conferences. Mangalam is also an artist and paints in various mediums. She ran an art school and has conducted art workshops as well as exhibited and sold her artworks. She lives in Bengaluru, India and enjoys playing and watching movies with her son.
Writing this book has been a dream come true for me. It has been harder, but more enjoyable than I thought. It took a lot of encouragement, patience, and support from everyone—family, friends, and colleagues to make this happen. This is such a special milestone for me, and I want to thank everyone who helped to make this book a reality.
First, to my dearest little boy, Siddharth. You compiled your first book when you were eight. You’re my inspiration and my superhero! Thanks for encouraging me to write, for giving me my space and reviewing all the quotes in the book. Thanks for all the hugs too. You keep me going.
Mom and Dad, thanks for always believing in me. I could never have made it this far without your unconditional support and love. You taught me to aim high and never settle for less.
Jaiku, Uma, Viku, and Shruti, thanks for always cheering me on and for making me feel special. To my besties, Arundhati, Sujata, and Subhashri. Thank you for always being there for me. To Gru, for being my sounding board and helping me think through my ideas. Thank you for your immense patience.
To Preethi Madhu, thanks for being my mentor, and showing me the path when I needed it the most. To Nishant, thanks for introducing me to the publishers. Thanks to all my colleagues, past, and present. I have learnt so much from you.
Finally, I want to thank the publishers, reviewers, and the editors for all your valuable comments, feedback, and suggestions. Your inputs have helped me articulate my views better and bring this book to the great shape it is today.
About the reviewer
Greg Cohen is a 20-year product management veteran with extensive experience in understanding customer needs and collaborating with development to create market-driven products. He is an expert and strong advocate of customer-centric design and agile development, and a pioneer in applying lean methods to product management.
Greg earned an MBA with honors from Babson College and a Bachelor of Science in Mechanical Engineering with second major in Electrical Engineering from Tufts University.
Greg is the founder of Agile Excellence LLC. He has worked and consulted for venture start-ups and large companies alike, including Software-as-a-Service (SaaS) products, data analytics, and medical diagnostics and devices.
Greg is the author of the books, Strategy Excellence for Product Managers, Agile Excellence Press (2017), Agile Excellence for Product Managers, Super Star Press (2010), and 42 Rules of Product Management, Super Star Press (2013). He is the former President of the Silicon Valley Product Management Association as well as a speaker and frequent commentator on product management issues.
Packt is Searching for Authors Like You
If you’re interested in becoming an author for Packt, please visit authors.packtpub.com and apply today. We have worked with thousands of developers and tech professionals, just like you, to help them share their insight with the global tech community. You can make a general application, apply for a specific hot topic that we are recruiting an author for, or submit your own idea.
Preface
Product managers need to have the skill to step between a blurry 30,000 feet view and a close-up fine-grained view. Today, businesses are competing to innovate. Cost is no longer the constraint. Execution is. When competitive advantage for business is paramount, customer delight is non-negotiable, opportunities for impact are abound, product managers have to improvise on their strategy every day. The need to be Agile is about responding to abstract feedback from an ever shifting market. This book is about finding the smartest way to build an Impact Driven Product that can deliver value to customers and meet business outcomes when operating under internal and external constraints.
When starting on a new product, it can be quite hard to determine which product idea to pursue. Is there an objective metric to compare an idea’s value? How can we factor engagement from all aspects of the business to create an impactful end-to-end product experience?
The book introduces the concept of investing in Key Business Outcomes as part of the product strategy. It can help elicit the stakeholder’s investment in the execution of an idea. The book is a handy guide for product managers and to anyone embarking on a new product development to align their product strategy with business outcomes and customer impact.
Who this book is for
If you are leading a team that is building a new product, then this book is for you. The book is targeted at product managers, functional leads in enterprises, business sponsors venturing into new product offerings, product development teams, and start-up founders.
What this book covers
Part 1 – Defining what to build, who we are building for, and why
This part guides the reader to define the Impact Driven Product starting from the business model and working down to the details of Key Business Outcomes, customer value, success metrics and cost versus impact for every feature.
Chapter 1, Identify Key Business Outcomes, addresses defining the business model, understand Key Business Outcomes and defining an Impact Driven Product.
Chapter 2, Invest in Key Business Outcomes, introduces the concept of investing in Key Business Outcomes and the value of business agility in product development.
Chapter 3, Identify the Solution and its Impact on Key Business Outcomes, introduces the concept of feature ideas in a product backlog and introduces a framework to evaluate/ prioritize ideas based on the estimates impact on Key Business Outcomes.
Chapter 4, Plan for Success, addresses the need to define a shared view of success and how to define success criteria for feature ideas.
Chapter 5, Identify the Impact Driven Product, introduces value mapping by defining impact scores and understanding risks and costs of a product feature.
Part 2 - Are we building the right product?
This part guides the reader to define the right metrics to effectively measure product progress and performance.
Chapter 6, Managing the Scope of an Impact Driven Product, addresses the limitations of a Minimum Viable Product and the need to think about the end-to-end product experience when defining product feature scope.
Chapter 7, Track, Measure, and Review Customer Feedback, addresses the importance of customer feedback, feedback channels and how to incorporate feedback into the product backlog.
Chapter 8, Tracking Our Progress, addresses how we can track product performance by measuring qualitative and quantitative metrics and also understanding impact of metrics on product strategy.
Part 3 - Are we building the product right?
This part guides the reader to understand and identify processes that hold product teams from delivering maximum value and why it is important for product teams to discard wasteful processes and stay lean.
Chapter 9, Eliminate Waste – Don’t Estimate!, addresses some common pitfalls of software estimations and the need for teams to embrace/discard the need for estimations based on product context.
Chapter 10, Eliminate Waste – Don’t Build What We Can Buy, addresses the importance of building what the customer values the most - Feature black holes that eat up a team’s time, parameters to consider to enable a build versus buy decision.
Chapter 11, Eliminate Waste – Data Versus Opinions, explains the importance for product teams to have a data strategy, common pitfalls with data, and the importance of data driven decision making.
Chapter 12, Is Our Process Dragging Us Down?, addresses the typical process bottlenecks and offers guidelines to overcome these process bottlenecks.
Chapter 13, Team Empowerment, addresses why team empowerment is important for building successful products and what an empowered product team looks like.
To get the most out of this book
Familiarity with Lean Canvas, User Story Maps, Agile principles can help, but are not impediments to the reader.
Download the color images
We also provide a PDF file that has color images of the screenshots/diagrams used in this book. You can download it here:
https://www.packtpub.com/sites/default/files/downloads/LeanProductManagement_ColorImages.pdf
Get in touch
Feedback from our readers is always welcome.
General feedback: Email [email protected], and mention the book’s title in the subject of your message. If you have questions about any aspect of this book, please email us at [email protected].
Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book we would be grateful if you would report this to us. Please visit, http://www.packtpub.com/submit-errata, selecting your book, clicking on the Errata Submission Form link, and entering the details.
Piracy: If you come across any illegal copies of our works in any form on the Internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.
If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit http://authors.packtpub.com.
Reviews
Please leave a review. Once you have read and used this book, why not leave a review on the site that you purchased it from? Potential readers can then see and use your unbiased opinion to make purchase decisions, we at Packt can understand what you think about our products, and our authors can see your feedback on their book. Thank you!
For more information about Packt, please visit packtpub.com.
Part I. Defining what to build, who we are building for, and why
Chapter 1. Identify Key Business Outcomes
Modern product development is witnessing a drastic shift. Disruptive ideas and ambiguous businesses conditions have changed the way that products are developed. Product development is no longer guided by existing processes or predefined frameworks. Delivering on time is a baseline metric, as is software quality. Today, businesses are competing to innovate. They are willing to invest in groundbreaking products with cutting-edge technology. Cost is no longer the constraint—execution is. Can product managers then continue to rely upon processes and practices aimed at traditional ways of product building? How do we ensure that software product builders look at the bigger picture and do not tie themselves to engineering practices and technology viability alone? Understanding the business and customer context is essential for creating valuable products.
This chapter addresses the following topics:
We are driven by purpose
Honeycombs are an engineering marvel. The hexagonal shape of honeycombs is optimized to reduce the amount of wax needed to construct the hive, while maximizing the storage capacity. However, building wonderfully crafted honeycombs isn't the raison d'être of the bees. The goal of their existence is to maximize their chances of survival, to keep their lineage alive. Every bee activity is centered around this.
The need to maximize chances of survival is true for nearly every living species, but that does not mean that the queen of the ants should ask her ant army to construct ant hills with wax in hexagonal tubes. It doesn't work that way. Every species has an integral DNA that defines what it eats, how it socializes, how it defends or attacks, how it adapts, and how it survives.
The engineering that went into the honeycomb contributes to a specific way of life that is suited to the bees. It is important to realize that the very first bees didn't initially build wax hexagonal tubes. They iterated over many generations and responded to feedback from nature (which is often harsh and can result in extinction). Bees have pivoted to this model and it seems to have worked rather well for them. Heck, they've even managed to find channel partners in humans!
In the product world, understanding outcomes and user goals is essential to building successful products. A product's success always relates to the end goals it meets. Engineering in isolation adds no business value. The same can be said about marketing or sales. Business functions acting in isolation, without the context of business outcomes or creating value to the customer, are not sustainable. The sooner we define end goals, the better for the business as a whole. After all, we don't want to end up building honeycombs for ants.
Business context defines everything we do
"Universal law is for lackeys. Context is for kings."– Captain Lorca, Star Trek: Discovery.
When the Agile manifesto was created in 2001, software practitioners were calling for a change in the way that software was delivered. The waterfall model of software development, which was predominant, required that software specifications and business requirements were frozen upfront. There was very little room for change. Change had to be avoided because changing anything midway would increase costs and timelines. Waterfall had evolved as a way to handle software development processes based on the limitations of the software technology of that time. Much of software development then was about automating manual processes or building bespoke technology solutions. Technology has since evolved a lot. It has become increasingly flexible and inexpensive to build technology solutions with direct consumer impact. The focus for software builders has expanded to include customer satisfaction and is no longer about just meeting budgets and timelines.
There are many frameworks (Scrum, XP, and so on.) that offer a methodology for software teams to focus on user experience and customer value. They foster team collaboration and enable teams to respond to change. The guiding principles behind these frameworks are noble, but failures always happen in how these principles are put into practice.
Without context, intent, and outcomes being defined, even well-meant advice can go waste. This is because we're humans and not honeybees. We are driven by purpose, we are lazy and we are imaginative. People can conjure up images of success (or failure) where there is none. They plan, speculate, and adapt. They try to optimize for imagined future situations. We know that a sense of purpose is crucial to rallying a group of diverse, independent, and creative people to come together and effect change (or even build great products). The problem is this is exactly where we seem to fail time and again.
We fail because we focus on the wrong stuff. We try to predictably measure productivity in a creative profession. We over-engineer solutions to nonexistent use cases. Software engineering is an interesting field of work. It's like an artist and a mathematician coming together to generate business value! Yet, we treat software engineering like automobile manufacturing. I know amazing software engineers who can churn out beautiful and working software, but their pace of delivery is not predictable. Every person has their own pace, and style of working, which is a problem for project managers. When we have strict timelines and budgets to meet, how do we commit if there is so much subjectivity? Software teams have spent a lot of time inventing processes to accurately predict engineering efforts. Estimations, planning activities, functional scoping, and progress reporting have gained a lot of visibility in this context. We focus too much on engineering practices.
Software product development is missing out on a great opportunity here. By carrying over software delivery frameworks of meeting timelines, budgets, and customer satisfaction, we are in a way restricting ourselves to looking at outputs instead of outcomes. It is time that we changed our perspective on this. Product management shouldn't be about measuring effort or productivity. Product management shouldn't be about measuring output. Instead we should focus on product outcomes. What value are we creating for the customer? What outcomes is the product helping the business to meet? How can we execute a plan to achieve this in the smartest way possible? So how do we measure these outcomes?
What influences product success?
In the good old days of business process automation (until late 1990s), measuring success seemed much simpler. Software teams could say, "There is an existing way of doing things. Let's automate that, but stick to budgets, timelines and quality metrics." Goals were simple and measurable. Software design was never discussed. User experience was nonexistent. Business impact was purely profitability based and no behavior changes were hinted at. Even as we moved into the era of Agile, business folks would give us weird looks when we asked to speak to end users. A client once told me, rather dismissively, "We're building this (app) for accountants. They don't have an eye for color. I don't know why you're worried about user interface or design." He may have made total sense a decade ago.
Today, you'll easily hear a CEO say things like, "We need to create stickiness, and to ingrain in our users a desire to engage with our apps." Many a product manager will roll their eyes and think, "Whatever that means." Success for a product is no longer about meeting budgets or timelines. The narrative of software development has changed. Can product management afford to lag behind?
Understanding business goals and evaluating risks and costs have always been essential for driving trade-off decisions. Business goals today are multidimensional and so are risks. How we make trade-off decisions depends on what aspects of product success we want to consider. Today, a product manager has to handle many facets of goals and risks, before defining the right product to build and driving trade-off decisions. According to the management consulting firm, McKinsey & Company, "Product managers are the glue that bind the many functions that touch a product—engineering, design, customer success, sales, marketing, operations, finance, legal, and more. They not only own the decisions about what gets built but also influence every aspect of how it gets built and launched."
Traditional project planning isn't going to help anymore. Product managers are in the driver's seat. We have to steer the product to meet ambiguous business goals. When building disruptive products in ambiguous business conditions, there is no "existing way" to refer to. All we have is a bunch of glorious ideas. So, the first step to demystifying goals is to articulate intent.
Impact Driven Product development needs to consider four key pieces of input that influence and guide product success:
A business as a whole has its own value creation goals outlined. A product may address some or all of a business' goals.
A business model
A business model is a starting point for identifying a product idea and drawing up a plan. The desired outcome of this plan is to identify the unique value proposition that our business intends to deliver to the users/customers. In order to arrive at this, we need to define who our users are, what problems we're trying to solve, what channels we can leverage, who our competition is, how we plan to make our revenues, and what costs we might incur.
For start-ups, or businesses in the early stages of development, Lean Canvas, or any other framework that can help to visualize the market, business ecosystem, unique value proposition, and target segments, is a great place to start. Even for a product manager joining a team midway through product development, understanding the vision, market and target groups, and so on is key. After all, context is king. If the business model hasn't yet been laid out, then I recommend that you do that first.
Lean Canvas is a fantastic tool for capturing the business model around a product. Product Vision Board is also another tool to help us to visualize the product vision. Defining the business model around the product is a great way to define the target customers, the problems we're trying to solve for them, and the unique value proposition that we can offer. This can form the basis of how we want to run our business. Not every aspect of our business needs to be productized. Also, not every user segment may value every product feature with equal merit.
The business model can help us to visualize these target segments and capture which segments we want to go after in the current phase of business. However, Lean Canvas stops at the business model level. When investing in technology, we need to be clear about the outcomes we seek and the trade-offs we need to make. Building a product requires that we understand the larger business context, but we iterate on a product strategy that helps us to deliver a solution that meets business outcomes and provides value to customers. Software technology is extremely flexible. We can build quick and dirty solutions, or we can build robust, long-lasting solutions. However, every product must be based on business and customer motivations, and not on technology preferences.
The following is the Lean Canvas model proposed by Ash Maurya:
The overall business plan may also vary depending on the stage of the business. Business context and constraints have a bearing on what is achievable. For instance, at early stages, a business may be interested in creating value for early adopters. Some businesses may not attach importance to revenue generation until there is sufficient traction. As a business scales, other goals may become important. Value creation becomes more comprehensive.
This relationship between business outcomes, a customer value proposition, and an execution plan can be represented as shown in the following diagram:
Case study
Throughout this book, we will use a sample business case to illustrate concepts. We will use an imaginary business called ArtGalore, which is an art gallery specializing in curating premium works of art. The company now wants to venture into creating a digital art viewing and purchasing experience for premium art buyers.
Let's look at the Lean Canvas model created for ArtGalore. The following is a sample representation:
In the preceding Lean Canvas model, the unique value proposition describes the concept of a digital art buying experience, the success metrics define the business goals, and the solution describes how the business intends to deliver the value proposition to its clientele. At the stage of problem/solution fit, the actual execution plan of how this digital experience will be created is not yet finalized. Even the value proposition, target segment and solution are yet to be validated. The Lean Canvas model represents the big hypothesis that the business is making about its growth in the next two years. The Lean Canvas model, in a way, also represents a slightly longer-term view for the business. Along the way, as the business discovers more about the customer's perception of value and actual growth indicators, the canvas could change and ArtGalore could pivot to a different business model if the hypotheses are proven wrong.
From a product development perspective, we need to identify the three aspects of product success discussed earlier in this chapter.
Defining business outcomes that the product can deliver (why?)
What does the business hope to achieve by investing in a digital art gallery? The success metrics shown in the Lean Canvas model are a broad indicator of long-term goals. Building a brand and doubling revenue are long-term goals. In order to work toward those goals, the business needs to make some product investments in the short term.
Defining the value proposition that the product will create for the customer (what?)
The unique value proposition, and the solution concept, coupled with the customer segments, as described in the Lean Canvas model addresses this. It is natural for us to jump into ideas about product features, but before we even arrive at features, we need to think about user personas in our customer segment, and define how the solution will help to deliver the unique value proposition to them. Eventually, the features get refined into product functionality.
Defining the execution plan (how?)
There can be many ways to deliver the value proposition to the customer and to meet business outcomes. The execution plan for delivering the value proposition and business outcomes can depend on the ease of execution, cost of execution and, potential to create a positive impact on business outcomes. While the preferred solution for ArtGalore is a digital art gallery, not all aspects may need to be built in upfront. The execution plan must factor in the strengths of all the business functions that exist in ArtGalore. The focus must not be just about how technology can solve all customer problems/meet business outcomes. The focus must be about how to work seamlessly with business functions and ensure that the end-to-end product experience is satisfying.
Business constraints and market influence
Business constraints includes factors such as the time available to go to market and the potential to raise investments. Governing policies, regulations and compliances (if any), technology potential, capabilities, skills available, and so on can also influence business goals and the product experience. These factors will determine the key goals to focus on, the product features to offer, and the best way to implement them. In addition to constraints, the intrinsic business intent is important. What are our uncompromising principles? What do we value more? What values drive our decisions? What is our appetite for risk? These factors will decide how we deliver value.
A product can impact the business or the organization that is creating the product. It can also impact the customers who will adopt the product. An Impact Driven Product therefore is one that finds the best way to deliver value to customers and meet business outcomes under internal and external constraints.
Based on the unique value proposition and the business context and business outcomes prioritized for a specific time-bound milestone, the following is a sample illustration of the inputs for product development for ArtGalore:
This is quite a simplified representation of the product development inputs at a given point in time. The diagram illustrates how business constraints may influence what the Impact Driven Product may deliver to the user.
The preceding illustration indicates that the most important outcome for ArtGalore is to become the first choice for art among its target segment. The most important aspect of the value proposition is offering tastefully curated art collections for existing buyers who don't have this information today. The most effective plan to execute this solution is to offer digital newsletters, provide an online sign-up for upcoming art shows, follow up on the sign-up with invites, and announce the website. This has been identified based on the business constraints of being ready for the upcoming art show, not compromising on the existing buyer experience, and so on. The other solutions, value propositions, and execution plans are also great, but given the business constraints, the Impact Driven Product is where we want to steer all our resources to.
Minimum Viable Product versus Impact Driven Product
Minimum Viable Product (mvp) is a concept that is quite prevalent in the software development scene. There are different interpretations of the concept of an mvp and Chapter 6, Managing the Scope of an Impact Driven Product dives into the interpretations of minimum viability.
At a basic level, an MVP intends to test the riskiest proposition of a business idea or a technology, without running out of resources. This is very helpful when testing an unproven technology or when building under tight business constraints. However, an mvp falls short in terms of delivering an end-to-end product experience to the consumers. The problem with how we define an mvp is that we tend to view technology viability as a value driver operating in isolation. An mvp is great in the problem/solution fit stage, but in the product/market fit stage, there are many other aspects to consider. When launching a new product, there are umpteen activities that need to be orchestrated to ensure success. Marketing, sales, support, and other operations need to come together to ensure a product's success. Testing viability of a product in isolation isn't going to ensure success for the business.
In my start-up, we had built up a platform for businesses to design and build mobile apps for client engagement. We had started out in the events and conferences domain, where app creation lead times were pretty low, audience engagement was critical, and last-minute changes to a schedule were quite common. Our platform was geared toward addressing those needs, but we soon started seeing interest from other business verticals who saw the potential that our platform had in driving customer engagement. One such business asked us to enhance our platform with the bespoke functionality.
We were in early stages in our start-up and naturally we got quite excited about the opportunity. The possibility of opening up our platform to another domain was quite lucrative. While we didn't see much value in creating a custom solution for a single client, we realized that we could enhance our platform to cater to the entire business vertical. This would also give us a great opportunity to launch our product into the B2C space. So, we carved out an mvp for this, and our engineers got busy with re-architecting the platform to make it flexible across business verticals. After spending more than a month on this, we were more or less ready with the revamped software.
Our revamped product was technologically viable. Yet, was the revamped software impact-driven? No. Why? We hadn't looked at the end-to-end value of the product. Our business model was different. Our target audience was new. A B2C market needed a very different approach. We hadn't planned for marketing, content creation, and promotions. We realized that we had neither the right skills nor the investment to drive this product to success. We hadn't really defined to ourselves what the new product would deliver. After all, we had just one customer who was interested. We hadn't looked at an end-to-end product experience.
Our rookie mistake cost us a month. We ended up shelving the product and didn't even close our sale with the one customer who showed interest. From the software perspective, we had it all covered, but we had not given any thought to the whole product experience or to the outcomes it could generate for our business. We are much better off today having learned and recovered from that mistake quickly, instead of having gone down that path, purely riding on the viability of our platform. We had looked at one customer's request and created a hypothesis about the problems our new platform could solve and the needs it could satisfy for that customer segment. We were confident that the product would address their needs and it could have. However, we hadn't given any thought about what it meant for our business, the stage we were in, our internal capabilities, and our weaknesses.
I know many developers who take great pride in how their software is built. The prevalent thinking is that if you build your software right, it will take care of itself. I've seen very smart engineers express deep disregard for supporting functions. They look down upon marketing, promotions, and sales saying, "People will adopt our product because my software is great." However, success isn't in and of the technology process itself. This is a core difference between task-oriented thinking and goal-oriented thinking.
