Tag Archive for: product development

Just because a device is smart, doesn’t mean it’s safe. That’s the October message from the FBI about connected products, such as home automation and security systems, medical devices, and wearables.

In its recent statement, the FBI expressed concern about the vulnerability of unsecured Internet of Things (IoT) devices, which criminals could compromise to launch attacks on other systems, steal personal information, jeopardize physical safety and more.

The FBI didn’t mention any imminent attacks, but experts are paying serious attention to a powerful strain of IoT attack malware, dubbed “Reaper” and “IoTroop,” that may have already infected a million organizations, according to KrebsOnSecurity.

And while there are a variety of preventative measures consumers can take, such as frequently changing passwords and installing patches, the burden of ensuring hackers don’t gain access to unsecured connected devices can’t totally fall on the public. Improved security is also the responsibility of companies creating smart devices, and many are being called on to step up their game.

Designing Better IoT Security

The US Food & Drug Administration (FDA), for example, says it’s examining security gaps and safety risks in connected medical devices, reports HealthcareITNews. As part of its efforts, the FDA has created a risk management program utilizing resources from the National Institute of Standards and Technology (NIST), and is also instructing companies to focus on security during the product design process.

Whereas industries like healthcare must adhere to government-mandated regulations, consumer electronics — which is producing a huge portion of connected devices — does not.

That’s likely one of the reasons British chip-making company Arm just unveiled its Platform Security Architecture (PSA), which has support from companies like Google, Sprint, and Cisco. Arm’s PSA is a new, open-source, architecture system designed to act as a common development framework companies can work from to ensure their IoT products are safer.

As described by MIT Technology Review, think of PSA as a “set of free, open-source documents and code that define how a device’s software and firmware should be designed to make it secure—a kind of checklist and corresponding set of tools that should, in theory, help device makers build wares that are harder to hack.” At the moment, Arm has released the first draft of PSA specifications for its partners, with a wider, public release targeted for early 2018.

Moving Faster on IoT Development

Now, one of the biggest challenges is getting IoT product companies to take threats more seriously, and begin incorporating stronger security measures into their design.

In the recent Harvard Business Review Analytic Services report, “Bridging The Gap In Digital Product Design,” for example, just 24% of companies creating smart products said managing and securing large amounts of personal data gathered from connected devices is a major challenge.

That number was surprisingly low according to one expert quoted in the report, Hans Brechbühl of Tuck’s Center for Digital Strategies, who says it could mean that many companies don’t understand how big the issue is. “If your product or service gathers a lot of data, you’d better be ready to handle it,” Brechbühl says within the report.

If companies creating IoT products are looking for immediate ideas on how to begin remedying security gaps during development, there are certainly places to start. Better requirements management ensures products do what they’re designed to do, and decreases the amount of defects or vulnerabilities in its final release. Improving collaboration between development teams, specifically hardware and software, will also go a long way in averting inadvertent security blind spots.

For more insights on how product companies can tackle security of smart devices, check out our blog post, “One of the Biggest Security Problems Smart Product Developers Are Missing,” and the report, “Bridging The Gap In Digital Product Design.”

Today, most consumers research products online before purchasing. Doesn’t matter if the product is B2C or B2B, or even if there’s a single competitor in the marketplace. You can bet customers are searching for opinions on your product, as well as alternative options.

“We are seeing the growing power of a customer in driving perceptions of brands/products, and reviews is just one way,” Tom Collinger, Executive Director of the Spiegel Research Center at Northwestern University, wrote in an email to Jama Software.

Recent research has highlighted the ways in which consumers perceive online reviews and how they inform purchasing decisions. And from that has come insights into how companies can think about online reviews — including why negative ones aren’t all bad — as well as ideas for future-proofing from backlash.

Value of Online Reviews

Researchers at the Institute of Cognitive Neuroscience at University College London, for instance, recently looked at how online reviews influence the perception of a product. The study first had 18 participants rate a range of Amazon items based only on image and description. The subjects were then asked to score the products a second time, but were instead shown the image along with aggregated user reviews, which displayed the average score and total number of reviews.

Turns out the subjects’ opinions were very much swayed by reviews, as their second round of ratings fell somewhere between their original score and the average. As Science Daily notes, “Crucially, when products had a large number of reviewers, participants were more inclined to give ratings that lined up with the review score, particularly if they lacked confidence in their initial appraisals, while they were less influenced by ratings that came from a small number of reviewers.”

As the study showed, people leaned more toward group consensus when their confidence about a product’s overall quality was low and the pool of reviews was large. Anecdotally, this seems to track. If you see a product online with over a thousand five-star reviews versus one with just two five-star reviews, you’re probably more likely to trust the one with more reviews, since it appears more credible.

Importance of Average Scores

Not that products with tons of 5-star reviews receive a blanket pass. Another recent study on the power of online reviews, this time conducted by Northwestern University’s Spiegel Research Center, in conjunction with the platform PowerReviews, analyzed millions of customer experiences from online retailers.

Northwestern discovered that products with near perfect scores can sometimes appear almost too good to be true. “Across product categories, we found that purchase likelihood typically peaks at ratings in the 4.0 – 4.7 range, and then begins to decrease as ratings approach 5.0,” the report states. So while you shouldn’t seek to attract purely negative reviews, some can help your product’s authenticity.

Beyond that, Northwestern also detailed some other ways in which negative reviews can help a product. By displaying at least five reviews online, positive or negative, the purchase likelihood is 270% greater than that of a product with zero reviews, according to the study.

Importance of Early Reviews

The study also discovered that nearly all increases in purchase likelihood of a product from online reviews occurred within the initial 10 reviews posted, with the first half of those being the most influential.

Of course, not all websites display reviews the same way. Some sort by review quality over chronological order, for instance. For the purposes of this research, the first five were found to be the most important regardless of how they were presented. “Our analysis describes the first five the consumer sees,” Collinger wrote in an email to Jama Software. “This is independent of the way in which they are listed by the retailer.”

This is why it’s so important for a company to get a product right at release. If a new offering gets savaged by a wave of online reviews initially, regardless of how they’re sorted on a website, those will be the first and most influential opinions people read when considering a product. And that reputation can stick. Patching the problem in future releases well help, but then you’re counting on people updating their reviews later on, which is no sure thing.

Good Products Come From Good Processes

When managing online reviews, the Northwestern study urged companies to focus on the first five reviews, embrace critical reviews, and follow-up purchases via email to urge consumers to write reviews. In fact, reviews from actual, verified buyers — as opposed to those who post reviews anonymously — are more likely to be positive than negative. Also, making it easy for buyers to post reviews on a company’s website, for instance, regardless of their device or platform, was recommended.

From a business standpoint, one other fundamental way to get online reviews working in your favor is by releasing the best product possible. That starts with a solid development process, with plenty of quality safeguards in place.

Best practices like implementing test management early and often, for instance, will reduce the number of defects or bugs that are likely to show up in your final release. Often, it’s exactly those types of design misfires that’ll get a product maligned by early online reviews.

And while ensuring the quality of a final product is a key factor of success with online reviews, according to Collinger, it doesn’t stop there. “Getting the entire customer experience right is the very simple solution to leverage this growing customer influence,” he wrote.

Bridging the Gap in Digital Product Design

Digital technologies are converging with traditional products at dizzying speeds. This fast-paced, integrated evolution is changing product development, and many companies are struggling to retain their footing.

Despite the shifting landscape, one thing remains clear: an excellent product requires a solid development process. Helping companies improve product development is at the heart of what Jama Software does, but we know this complex practice extends far beyond our platform.

To get a better feel for the methodologies and pain-points teams are facing creating connected products, we sponsored a Harvard Business Review Analytic Services study. The resulting report, “Bridging The Gap In Digital Product Design,” features insights from nearly 300 innovators from a variety of industries, including manufacturing, technology, healthcare, financial services, and more.

What We Discovered

While we knew connected products were becoming more prevalent in our everyday lives, that trend has only just begun. A full 86% of organizations in our study have either applied digital technologies to their existing products or services, or are in the process of doing so.
86% of business and IT leaders are developing smart products or planning to
For many businesses, adding software to their physical products is already a challenging proposition. It’s compounded by stress from new competitors threatening disruption. To maintain an edge in this new reality, companies are being forced to act fast, and that’s placing significant strain on the development process.

In fact, 80% of those implementing digital technologies say they feel either somewhat or significantly added pressure to increase time to market for products and services. And an even greater majority (89%), expect that pressure to grow in the future. According to the report, some of the other big challenges businesses are facing with this transformation include ensuring new smart products work within the ecosystem of other connected devices, the clashing of traditional and digital product design, and trouble staffing and training the right employees.
89% of business and IT leaders expect somewhat or significant increases in time-to-market pressure from implementing digital technologies
When implementing any new process, there’s bound to be some unforeseen obstacles along the way. For instance, just 24% of respondents in the report identified the need to manage and secure customer data as a major challenge. The problem is many organizations may be underestimating this responsibility, according to Hans Brechbühl, executive director of the  Glassmeyer/McNamee Center for Digital Strategies at the Tuck School of Business at Dartmouth, who was interviewed for the report. That’s because while the constant flow of usage data can be advantageous for informing future product iterations, companies inexperienced in managing this information may not realize the evident risks.

What’s Next

There are so many valuable insights and trends within “Bridging The Gap In Digital Product Design” it’s more than will can fit into a single post. That’s why we’ll be diving deeper into some of the themes and findings in the coming weeks with a dedicated blog series, featuring observations from Jama Software experts.

And let me know any feedback or questions in the comments below. With so many major industries refreshing product offerings with connected devices, the conversation about the best methodologies for improving and maintaining this process is just getting underway.

Developing new products is hard. Herculean efforts are required to take a concept all the way through the development process to launch. On top of that is the constant pressure to build faster, smaller, with higher quality at less cost than the last generation. Teams have to read the tea leaves to pick which features consumers will want, and architect a solution that will resonate at a certain price. Of course, these product development teams also have to worry about an army of competitors trying to get to market first.

If all of that wasn’t enough, the development landscape is constantly evolving. This article will explore five ways in which the world of product development is changing, and how these trends will impact teams building new products in 2017.

Software tipping point

At some point in last few years the contribution of software to typical new products became the majority of the development effort for the project. What does that mean? It used to be that a typical device consisted of hardware and some firmware. That firmware was the software that allowed the product to operate, and was, by today’s standards, quite simple and wasn’t updated often. Think about your old VCR, the firmware controlled the play, pause and stop buttons as well as the clock that flashed 12:00 for years at a time. Teams designing new VCRs back in the day spent the majority of their time working on the mechanical bits required to precisely drag the magnetic tape across the read head. Firmware for the VCR was important, but it was far from the largest task in the project.

Fast forward to today and the TiVo device sitting in your entertainment center. The TiVo media device is custom built computer with its own customer operating system and advanced software. Their hardware is quite complex, but clearly the software embedded in their device accounts for the majority of the development process.

As product development teams reach that tipping point and more than half of the effort is on the software side of the ledger, interesting dynamics start to occur within the team. The full effects of this shift are beyond the scope of this post, but as fast moving ‘agile’ software teams become more central to the development process their impact is felt within the entire development team.

Distributed teams

Talking about teams, they are becoming more dispersed across multiple geographies. Clearly there are many companies today working out of a single office, but the trend is to go where the talent lives. It’s not at all uncommon to see even small companies with a hardware team in Phoenix Arizona, a software team in Redmond Washington and a team of scientists working on the next great technologies in Madison Wisconsin. Typical product development processes become tedious across multiple locations and time zones. Stage gate reviews are tough enough with the entire team in one conference room, distributed teams are forced to find new collaboration tools to bring teams and project data together virtually.

Working within an ecosystem of products

It’s not enough for a new product in 2017 to just work well on its own. Many new products today have to work within an ecosystem of products to solve complex problems or create dynamic solutions for the customer. For example, at the Consumer Electronics Show last month a whole slew of smart home products were announced that are designed to work with Amazon’s Echo voice activated device. Consumers are less interested in stand alone devices and are looking for their products to work seamlessly together as a single network of devices. This creates complex challenges for product development teams. Which ecosystems should they target working with? Once a target is defined, what are the unique requirements that come along with that system?

Massive amounts of data

Today’s smart connected products are loaded with sensors; microphones, GPS location, cameras, temperature sensors, etc. Data from these sensors, along with the software to make sense of the data, create the unique customer experience. The data is also hugely valuable to product development teams as it can paint an accurate picture of product use, which shapes how the next product is designed. However, all of this data adds up and has to be managed. When autonomous car researchers starting recording the vast amounts of data produced by the array of sensors embedded into the car, they found that they could fill a normal computer hard drive every few seconds. For a product expected to stay on the road for a decade, this amount of data becomes an issue for the development team to manage.

Possible security event impacting views on privacy

All of this data also create questions of security and privacy. Many new products today could, in theory, be hacked to transmit your location, your images, or voice to bad actors.

In 1982 seven people were murdered when Tylenol capsules were tampered with and laced with cyanide. That event had a profound impact on how products were packaged and how consumers shop.

In consumer products we have yet to see a ‘Tylenol’ moment…an event that greatly raises shoppers understanding and feelings about smart connected product security. Not saying such an event will happen, but product teams need to be aware that if a security event happened, consumer views about their product security could be negatively impacted, so it’s best to be solid on privacy requirements from the outset.

It is no secret that Agile methodologies have changed the way software teams organize and have had an even greater impact on the speed and flexibility of the product cycle. In the old days, software was developed in silos between independent teams and put together at the very end. This resulted in clunky, redundant programs that had many errors that had to be reworked. Early versions of Microsoft Windows with tens of millions of lines of extra code is the classic example of a poor development process.

Today, Agile software development has taken over. Agile teams build their products in concert with one another and have visibility into everyone’s progress. Feedback is constant and any problems or duplications are discovered before the product is ready to launch. That allows a much more elegant product to emerge in a much shorter amount of time.

Most people associate the Agile method as a practice followed by software teams. This is changing thanks in large part to the overwhelming market for smart, connected products. Case in point, look at the automotive industry. It’s no secret that it is undergoing a revolution. Between radical technological innovation, new safety standards and shifting consumer attitudes, manufacturers must rethink and adjust their strategy. These changes have made automotive development much more complicated, forcing design teams to understand these complexities and adapt, adhering to new safety regulations such as ISO 26262, and prove compliance. As a result, there is a far greater need to use modern tools and technology to further evolve how they align teams, verify functional safety and ensure they are building the right products.

Applying Agile development to hardware requires a few basic parameters. First, everyone needs to be on the same team to see plans, progress and calculate the physical effects of one part on the rest. The high-costs associated with hardware development means it is especially important to have transparency. Altering a product once the architectural decisions are completed does not mean erasing a few bits of code and rewriting them. Instead, you are in the world of atoms and you may have to order new parts, apply heat to weld or add more microchips. All these add expenses and end up affecting the final price, and impact your bottom line. Applying Agile development processes will inevitably lower the price for hardware devices and result in more profit for the companies or lower prices for end consumers.

Hardware Agile development includes seven steps, as software Agile development does. Yet, the process is slightly different. Hardware Agile development starts with a design interface and moves on to a low functionality emulator. That is followed by a medium and finally high functioning emulator for the team to see. There are two layers of full functionality prototypes and finally a fully integrated testable device. The team shares an open platform to get to the product they are seeking.

The manufacturing process itself has also improved by leaps and bounds in recent years. Ever since Motorola developed its Six Sigma standard, companies have endeavored to upgrade their manufacturing speed, quality and accuracy while reducing price. Agile development is the next stage in this process as all team members can contribute to productivity improvements on the manufacturing line.

pd-feat-image

The “smarter” and more complex modern systems get, the more complicated the process required to build them becomes. Systems engineering teams working in regulated industries suffer an unfair share of the pain of product and systems development and management. In such industries, the margins of operation have always been tight, with little to no room for error, and maintaining product integrity is difficult.

As software becomes more and more embedded into technology, the rate of innovation accelerates. Connected software has also changed expectations. Customers expect seamless interaction with technology solutions across form factors and devices. They expect their technology will constantly evolve or update post-purchase. Many organizations have a hard time keeping up with the rapidly accelerating pace of change, especially when their teams work in silos using outmoded systems. Product development is often plagued by preventable delays, which can make or break your business.

Disruptive technologies are not seen as a threat but as an opportunity. Change is embraced rather than managed. The “old way” of sharing documents via email attachments and having meetings to discuss decisions doesn’t work when you need to move fast. Decision-making needs to happen in real time and everyone impacted by that decision or change needs to find out about it immediately — in the tools they are working in. Whether they are mobile, tied to their email or living in Agile developer tools, they still stay connected to the rest of the team.

The core of development — define / build / test — needs to be solid. In addition to defining all the features and functions, take time to understand, define and share the “Why.” Build with a very strong view of what outcomes the product should deliver to your customers. Most importantly, define and clearly communicate the business outcomes your product needs to achieve. Teams need alignment — business with product development, hardware with software, systems with components, buyers with suppliers—on what they are building so they don’t waste time on lower-importance features. When you define the why, you deliver faster.

1. EMPOWER BETTER DECISION-MAKING
If you and your team have a clear understanding of the “Why,” you can cut through discussions, trust that team members will make the right decisions and navigate through technical complexities. Allow team members to make fast, high quality decisions with an understanding of acceptable tradeoffs. Business leaders need full visibility into the progress and tradeoffs under consideration in development, and definers and developers should have full visibility into the expectations of the business. Decisions need to be captured and assigned owners, so everyone involved can initiate and record follow-on questions to visible resolution. Good decisions need context or situational awareness, an understanding of impact and a way to get input from others. By providing context, strong relationships, and understanding the why, your teams will be able react to the new information more effectively for better outcomes.

2. TIGHTEN UP YOUR TRACEABILITY
If you’re operating in a regulated industry, it’s crucial you demonstrate compliance to specific governmental, environmental, security or privacy regulations. You need traceability analysis that proves you have tested your product against regulatory demands and that your deliverable meets the terms of a contract. In development, traceability generally refers to engineering activities such as change impact analysis, change and risk analysis, and verification. Traceability also links all these activities back to the business rationale. Does this test fulfill customer needs? Does it accomplish business goals? When everyone across the organization involved in product delivery is connected, each individual can quickly reach out to teams or individuals for faster decision-making and evaluate all the up and downstream implications of decisions.

3. COLLABORATION WITH PURPOSE
Collaboration is the layer that brings everything together – people and data. The key to purposeful collaboration is keeping communication connected to the work. In modern product delivery organizations, collaboration ties the conversations and communication directly to the specific requirement, specification or use case in question. Decisions are not made outside the process or stored in locked documents or email. The conversations stay connected to the work itself for ready access and understanding.

4. REUSE YOUR IP
Companies leading the pack find ways to reuse their IP at every level. It started with code reuse, but now we see customers reusing entire IP blocks—design artifacts, specifications, test cases, content for data sheets and process information— at the outset of new development. With purposeful collaboration integrated into product delivery tools, the entire context of product development can be reused. Every conversation, every decision about changes can import into new projects, so teams can be confident they are using only the latest approved and validated information. The bottom line is that product development is a business issue; it cannot live in the development world and absolutely needs to be a strategic priority. Products will not get built faster or better by throwing more technology resources at the development and product teams. Customers are transforming their businesses to innovate and out-compete. Change is happening in the enterprise. At the end of the day, your business builds value from what you deliver to the market, so there’s nothing much more important than doing this right.

What’s on the Business Analyst’s wish list? Oh, plenty of illogical, unreasonable and preposterous things such as these evergreen dreams:

  • Increased product quality
  • On-time and on-spec product (and project) delivery
  • Less time waiting for input, feedback and decisions
  • Reduced time and effort spent on non-value-added activities, such as wrangling information, rehashing past decisions, tracking down why decisions were made, manually “connecting the dots” (this one’s a very long list)

Pity the smart and savvy but long-suffering B.A., whose goals are ambitious but wholly practical, yet too often feel like they’re beyond the realm of possibility.

Driven by data, yet driven nearly mad by bad processes, analysis can lead to paralysis if you’re not careful, because you’ve got so much to contend with:

Tall tasks:

  • Serving as a critical bridge between strategic need and tactical implementation.

Pressure points:

  • Translating customer needs into solutions that will work for many users.
  • Writing user stories that describe how a user interacts with a solution.
  • Creating process diagrams to describe business processes.
  • Assessing the impact of implementing a particular change.

Burning desires:

  • To have a development-to-launch product platform that operates within current workflows and methodologies and allows you to “own” every requirement that each team is working on.

With Jama, Business Analysts can turn frustrating “Land of the Lost” episodes into fast-and-furious “A-Team” epics.

How so? You’re able to…

  • Create a centralized, organized and accessible place to store all requirements.
  • Set relationships between requirements so gaps in process flows are identified.
  • Decompose high-level requirements into detailed system requirements.
  • Produce reports such as baseline comparisons, release plans and specs.
  • Communicate easily with the entire project team to get clarification and decisions made, regardless of location.

Read 2 Brains, 1 Product: The Builder’s Dilemma to learn more about the ways Jama makes your wildest (and possible) product delivery dreams come true.

Check out other ways Jama helps business and engineering teams get and stay aligned:

How Jama Helps VPs of Sales

How Jama Helps VPs of Product

How Jama Helps Systems Engineers

How Jama Helps QA Leads

How Jama Helps Product Managers

How Jama Helps Project Managers

“There are so many moving objects when managing a product. You must be aware of them all (managing vendors, internal politics, management structure, development teams, testers, project managers, designers, architects, businesses, customers, etc.), and like a game of chess, you must be thinking ahead several moves in order to react (or not) properly.
Nailed it. And, we would add, the processes you depend on to bring products to market must also adapt.

The many steps involved in building products—moving from product idea to release and, hopefully, to customer approval—have traditionally been relegated to product and engineering teams, at least until something goes wrong. Companies strive to update product delivery processes for the way business works today by involving stakeholders from multiple departments and including executive leaders. “Many hands make light work” goes the saying, the idea being that a collaborative, dedicated effort toward a shared goal should lead to desired results.

“Should” is the key word here. The challenges of integrating hardware and software, handling employees in multiple locations and different time zones, and dealing with immediate customer feedback, among many other things, adds a great deal of complexity to an already high-stress, fast-moving process. Companies recognize the business value collaboration can bring, but it’s much easier to advocate for than to organize and execute. Too often, collaboration devolves into design by committee.

Forrester Consulting conducted in-depth surveys with 150 senior business and IT professionals at enterprise organizations and found that a hefty one-third of companies release their products late. The top reason? A classic: Unclear or changing requirements. The surprising drag on reaching the finish line in time? Delayed decisions.

Executive leaders are the acknowledged decision-makers at the high level—giving the green light to build product X with Y specs for Z cost—but during the cycle of product development to release, no one has to make or push through more decisions than product managers. And at the rate 21st century companies conceive, build and release products, the time spent getting to market matters more than it ever has.

So while Matt Khoury astutely testifies to the many ways that product managers encounter problems on the path to release, we would add a note of caution for all companies who conceive and bring new innovations to market:

If you expect your employees to focus on outcomes, you need to adapt and you must also align teams; enable fast decisions, reuse and stakeholder involvement; iterate quickly and provide stakeholders and all participants with real-time context right up to the point of release.

The success of your product depends on it. Just ask your product manager.

The following guest post is the third in a series of four articles by innovation agitator Alberto Savoia (find the first here). Throughout his career as a serial entrepreneur and Google employee, Alberto has experienced great market successes–along with a few inevitable failures. In this series he’ll share his knowledge about why products fail and provide recommendations for beating the odds. 

________________________________________________

In my previous two articles (found here and here) I introduced The Law of Market Failure which states: “Most new products will fail in the market, even if they are competently executed,” and identified failure in premise (i.e. building the wrong product to start with) as the most common, and hardest to recover from, reason for failure. In this article, we begin to look at how we can test a new product’s premise before we invest too much in it.

All new products begin with an idea. If all you have is the idea, however, the most you can do with it is to solicit opinions based on it; and if you do that, you are likely to run into a couple of problems that may seriously derail your decision-making process:

The Lost in Translation Problem: An idea is an abstraction–and a subjective one at that; it’s something that you imagine or picture in your head. The moment you try to communicate what you see in your mind’s eye to someone else you run into a challenging translation problem–especially if your idea is new and different from anything else they’ve seen. The way you imagine the new product and its uses may be completely different from the way they imagine it.

The Prediction Problem: Even if your audience’s abstract understanding of your idea is a close match to your original intention, people are notoriously bad at predicting whether they would actually want or like something they have not yet experienced, or if and how they would actually use it.

In my book, Pretotype It, I introduced the concept of Thoughtland, a fictional place where unrealized and untested new product ideas live. In Thoughtland, every idea can be a winner or a loser–depending on whom you ask … and how you ask it. This can lead to two dangerous outcomes:

False Positive: People like your idea, they think they understand it and can see themselves using it. They give you thumbs-up and tell you to go ahead: “Go for it! If you build it, we’ll definitely buy it and use it.” Fueled by such positive feedback you proceed to implement the idea. But after you launch it, all that enthusiasm and all those plans to buy and use your product are nowhere to be seen.

False Negative: People just don’t get your idea, or it makes no sense to them. They don’t see what you see. When you talk about your vision, they think you are hallucinating: “Have random people follow you as you write 140 character blurbs? You’ve got to be kidding!” As a result, you drop any plans of implementing your idea and move on. And a few months later another company launches a very similar product to great success.

False positives can lead you to believe that your idea is immune to The Law of Market Failure, so you invest too much too soon in a new product that will eventually flop. False negatives, on the other hand, can scare you away from giving your idea a chance, and you end up prematurely scrapping the next Twitter, or Google, or Tesla.

To minimize your chances of getting false positives or negatives you need to collect something more substantial and objective than opinions–especially when the people who give you those opinions have no skin in the game. And the only way to do that is to transport your idea from Thoughtland to a more concrete environment–let’s call it Actionland.

In Thoughtland you use abstract ideas to ask hypothetical questions and collect opinions.

Thoughtland: Ideas -> Questions -> Opinions 

In Actionland you use artifacts to prompt actions and collect data.

Actionland: Artifacts -> Actions -> Data 

Let’s say, for example, that you have an idea for a computer monitor stand with sensors and motors that automatically moves and adjusts for optimum ergonomics. Let’s call it The Last Stand–as in: “You can now last longer working at your computer.”

If all you have is the idea and, perhaps, a drawing, you are stuck in Thoughtland. You can go around your office, explain the idea to your colleagues and ask them questions such as: “What do you think of this?”, “How much would you pay for it?” You can reach out to other companies and talk to HR departments: “Would you consider buying this for your staff?” “How many would you order?” That’s a lot of hypothetical questions and subjective answers (with no skin in the game)–not a lot to go on.

Of course, you might learn a few useful things in the process. For example, that most people would not use their own money on The Last Stand, but would be happy to try it–if the company pays for it. Before you make an expensive new product decision based on a flimsy combination of ideas, questions and opinions, however, remember The Law of Market Failure.

As I’ve mentioned in my first article: “In criminal law, a person is presumed innocent until proven guilty. When it comes to market law, we should presume a potential new product to be a failure–at least until we’ve collected enough objective evidence to make us believe otherwise.”

And to collect that objective evidence, you need to move from Thoughtland to Actionland.

You can do that by building a proper prototype of The Last Stand (i.e., an actual stand with sensors and motors–and all the software to run it.) But such a prototype will be costly and will take weeks/months to create.

On top of that, working prototypes are great for determining the feasibility of a new product (Can we build it? Will it work?) but are not sufficient for determining if there is a viable market for it.

Wouldn’t it be wise to objectively test and gauge the potential market for The Last Stand–at least a bit–before making a major investment in prototyping it? Are there other artifacts we use can to collect market data that are simpler, cheaper and quicker to build than a prototype? Yes, between abstract ideas and proper prototypes there are pretotypes:

Pretotype, noun: An artifact used to test hypotheses and collect data about the market appeal and actual usage of a potential new product objectively and with a minimal investment of time and money.

Pretotypes help you to “make sure that you are building The Right It before you build It right.”

In the next and final article in this series, Pretotype It, I continue my discussion of pretotypes and show you how simple pretotypes can quickly take you from Thoughtland to Actionland and be used to collect valuable market data. Please share your thoughts about decision-making in building products in the comments below.

Read the fourth and final article in the series: Pretotype It.

About Alberto Savoia

As a serial entrepreneur and an early Google employee (where he led the development and launch of Google’s AdWords), Alberto Savoia has experienced great market successes–along with a few inevitable failures. Most entrepreneurs and innovators respond to failure by licking their wounds and moving on to their next idea. But Alberto decided to first deal with the sting of failure by stinging back. Between 2008 and 2011, while still at Google, Alberto became a serious student of failure in new and innovative products. After reading dozens of studies and analyzing hundreds of new products, he was able to identify the main cause for why most new products fail in the market, and developed a set of techniques, which he called Pretotyping, to minimize such failures.

The concept, techniques, tools and metrics of pretotyping were an instant hit within Google; and soon Alberto found himself teaching pretotyping at Stanford University and at many companies, from startups to Fortune 500. His handbook “Pretotype It–Make sure you are building The Right It before you build It right” has been translated in many languages and has become an invaluable guide for thousands of innovators and entrepreneurs world-wide. Alberto’s work on innovation has been recognized with numerous awards, including The Wall Street Journal Innovator Award. Learn more about Alberto on his website and follow him on Twitter @Pretotyping.

 

The following is an excerpt from our whitepaper: Better, Smarter Faster: Accelerating Innovation Across The Enterprise.

Finding the right product delivery solution isn’t easy—there are a lot of different features to take into account. However, many innovative companies are finding that there are several key elements to look for in order to choose a solution that can power effective products—and empower efficient teams.

When considering a solution for your business, here are five key questions to ask:

Does it enable collaborative, reusable requirements management?

When you have a robust solution for requirements management and end- to-end product delivery, it’s possible to build highly complex products faster. The ability to reuse requirements can also help you reduce risk and control costs.

Can the solution provide comprehensive testing features?

In order to ensure test coverage and improve quality, it’s important to be able to link test cases to requirements, run test plans and
log related defects—while maintaining real- time visibility into overall product quality.

Will the solution support the diverse needs of multiple industries?

Every industry has its own set of challenges. This is true whether it’s a question of regulatory compliance and security for financial services, government or health care, or the need to handle massively complex products, as is the case for aerospace, software or telecommunications. The right solution must be flexible as well as customizable enough to meet the needs of every type of organization.

Does the solution easily connect the right people with right data?

It takes integrated, structured collaboration to give everyone the kind of comprehensive insights they need—in real time—so they can understand what their teams are building and why.

Are robust two-way integrations fundamental to the solution?

Bi-directional data sharing is powerful enabler to faster delivery and increased innovation, especially when you can connect to commonly used solutions such as JIRA, Rally and HP Quality Center.

Download the complete whitepaper now: Better, Smarter Faster: Accelerating Innovation Across The EnterpriseRead the first parts: The New Economic Reality,  Competition in Global Markets and Competition is Heating Up.