18
May 17

People Don’t Buy Capabilities, They Buy Knowledge

A visual of a head with gears where the brain goes, and knowledge spilling out of it.

This guy might have too much knowledge.

Knowledge is power

Most of our tools and applications deliver capabilities, but users and buyers are always hoping that what they’re buying is knowledge. Knowledge of how to do the job. How to do the job faster, or with fewer errors, or with better outcomes. If we don’t put the knowledge in, the our users have to figure it all out themselves. They have to become experts in our tools when they really just want to be experts in their job.

Even if it’s basic knowledge that everyone knows, putting it in your product will make your product more valuable. And of course, the more knowledge you can embed, the better.

There are a ton of good examples:

  • Instagram (filters)
  • LinkedIn (“The most successful profiles have…”)
  • SAP (the Reference Model)
  • iPhone (visual voicemail)
  • Slack (Slackbot, do this then that)
  • IFTTT (example recipes, that are then augmented by shared customer recipes)
  • Any product that has a setup wizard or onboarding process
  • And it doesn’t have to be built in – can be an email-based onboarding process
  • NetIQ (Knowledge Scripts)

It’s not an accident that all of these examples are market-leading or paradigm changing. Compare what they delivered in their product versus what their competitors delivered. With rare exceptions, the competitors were offering the same capabilities but not in the form of defaults or a pre-made experience.

Examples

  • Instagram: If you’re delivering a photo app, it’s obvious to include the capabilities of editing and adjusting the images. And most photo apps have that capability. But Instagram one-upped its competitors by putting well-designed default filters front and center. Users no longer had to learn how to adjust a photo to increase the drama or appeal. An expert had already figured that out, and Instagram put that expert in your hand. (This is one of the ideas in my bonus content for this post.)
  • iPhone Visual Voicemail: I’ve said before that the iPhone’s Visual Voicemail feature is one of my favorite examples of killer product management. Today it seems kind of boring, until you are faced with a Cisco Internet phone on your desk, for example. All of us can do regular old voicemail (like the stupid Cisco system). We just hate it! Visual Voicemail takes all that stuff that we used to have to do manually and hides it all behind a “knowledge-full” experience. The iPhone was the first cell phone with this feature built in according to Wikipedia.

Low hanging fruit

The good news for all of us product managers is that the bar is extremely low in this area. Most of our competitors are not putting knowledge in their applications. Chances are you’re not either. So a little bit of embedded knowledge can create a lot of differentiation.

The other piece of good news is that defaults and knowledge provide differentiation in two ways. First, they provide the knowledge. But almost as importantly, they make the customer feel like you care about them, because you gave them knowledge. How many Instagram photos use a different filters than the default? It’s a very small percentage. But the idea that those other filters are there is extremely comforting.

Put this idea to use

Here are three things you can start doing today to put more knowledge into your application so you’re not just selling capabilities. (Or get the freebie for these and an additional bonus idea!)

  1. Find out how experts configure or interact with your product. Then create templates based on what the experts do. For example, if your product is a project management system, how do experts configure their projects? Create a project template based on their configuration. If your product is a collaboration tool, how do experts set up their groups and notifications? Give your users the option to have their system set up with groups and notifications based on that model.
  2. Look for situations in your application where most users take the same steps in the same order, most of the time. Make this set of steps the default, and make it achievable in a single action. You might want to leave the other options available, but if most people are doing the same thing most of the time, make it very, very easy to do that thing. (This is an example of the knowledge of the crowd, not of an expert, but it’s still knowledge.)
  3. You can also use your own insights into how the product should be used to get the most value. This is especially valuable if your customers are not currently getting as much value as they could. Sometimes this is because the steps to achieve the value are complex, easy to forget, or error-prone. Sometimes it’s because you expect the user to do some work outside the application to achieve the benefit. A great example is retrospectives. All us tool builders know that our customers will be more successful over time if they do retrospectives. And there’s actually very strong research data that says how much more successful they’ll be. However, no (or very few) project management/collaboration/development tools actually support retrospectives directly. Even if you can’t do it perfectly, if you put that capability into your product and our competitors don’t have it, at minimum you have a good differentiator. Ideally your customers will actually get the value of the capability (retrospectives in this example), and that will enable them to beat their competitors.

Over to you

I’d love to hear your stories of how you’re putting knowledge into your application. Please leave a comment or drop me an email.

And if you have other good examples of applications that include knowledge, I’d love to keep building my list.


07
Oct 16

What Will Product Management Be Like In 5 Years?

The future is hard to tease out, but here's what will happen in product management's future. (CC 2.0 by PunkToad)

The future is hard to tease out, but here’s what will happen in product management’s future. (CC 2.0 by PunkToad)

Earlier this year Janna Bastow of ProdPad put out a call for opinions on the future of product management. I quickly responded then. And realized later it would also make a good blog post.

To understand the future of product management I started from the “present” of product management. Where are we now in the product management discipline?

The “Present” of Product Management

Product management today has these characteristics:

Where (I hope) product management will be in five years

  1. Product management will be understood to be more about finding market problems and solving them than about “product” per se.
  2. Businesses will understand that the activities and effectiveness of product management are the primary leverage the business has on revenue and profits. Small improvements in PM effectiveness have outsize effects on the top and bottom lines.
  3. The business value of PM – i.e., revenue per PM – will be well known and (somewhat) managed to.
  4. Product managers take strong control of their part of go-to-market.
  5. We will have escaped from the fetters of the old inherited IT lexicon.

Three things you can do

  1. Make sure you’re spending enough time on the most valuable product management activity – finding and validating market problems.
  2. Understand where you and your company are in terms of finance-related product management ratios.
  3. Think about the literal and connotative meanings of the words you use – requirements, features, roadmaps, applications, agile. Make sure you understand not only what you mean by them, but what others hear when you say them. And if those aren’t aligned, change what you say.

15
Dec 15

Interview With Hubert Palan, CEO of ProductBoard, Part 2 – Podcast Season 2, Episode 2

This second part of our interview with Hubert Palan is the third episode of our new podcast season of All The Responsibility, None Of The Authority, crossposted from alltheresponsibility.com. I will be crossposting the new episodes from the new site to this feed as they are published (I’m a little behind now but will catch up!).

This is part two of our interview with Hubert Palan, found and CEO of ProductBoard, and long time product management leader and executive.

Part 1 of the interview is here.

Three things you can start doing today

As always, we like to give you actionable takeaways from our podcast episodes. The three ideas below come directly from our interview with Hubert.

  1. Create a central repository, not just about the features you’re building, but about the market inputs you gather to help you find and validate the business problems you are solving. You can use a tool like Hubert’s ProductBoard, or you can try to roll your own (Nils had a podcast about this last year). This information comes from Support, Design, Product, Sales, Marketing, and your own conversations with customers and prospects. A central store of this input, and the relationships between this information and the product decisions it supports, helps mitigate some of the cognitive biases Hubert mentioned. And by gathering all this information together, you are better able to detect market signals in all the noise, and make better holistic decisions about the product.
  2. As Hubert pointed out many times in the interview, Context is King. Make sure your team, and your whole organization, knows not just what features you’re delivering, but what problems those features solve, and for whom. This not only simplifies many of the issues of prioritization, it also serves as a basis for communicating across segments of your organization.
  3. Clarity and communication are the heart of the Product Leader’s role. The better we get at clearly communicating about prioritization, context, and decisions made in the product team across the organization, the better the organization can execute on creating and selling solutions to customers.

Thanks to Hubert!

Rob and I want to reiterate our thanks to Hubert for participating in our new podcast as our first interview! If you want to learn more about ProductBoard, you can visit productboard.com. You can follow Hubert on Twitter at @hpalan, and ProductBoard tweets at @productboard.

As always, we’d love to ask two small favors from you:

  • First, please subscribe to the podcast on iTunes, or wherever you get your podcasts. You can access the podcast directly on this feed.
  • Second, please rate the podcast on iTunes or “recommend” it on your podcast app.

Finally, we really appreciate getting your opinion, so we’d love to hear from you in the comments, or via Twitter (@atrnota) and our Medium publication, All The Responsibility.


15
Dec 15

Interview With Hubert Palan, CEO of ProductBoard – Podcast Season 2, Episode 2

Here is the second episode of our new podcast season of All The Responsibility, None Of The Authority, crossposted from alltheresponsibility.com. I will be crossposting the new episodes from the new site to this feed as they are published (I’m a little behind now but will catch up!).

Introducing Hubert Palan

Nils first met Hubert Palan in November 2014 at the Product Management Summit in San Francisco. Nils was presenting some ideas on a “roll your own product management system of record,” while Hubert was there to talk about the product he was building – a real product management system of record. This product, ProductBoard, is now available, and it’s definitely worth checking out. Hubert is a serial entrepreneur, with innovative and incisive ideas about how product management as a discipline can be improved.

In this wide-ranging interview, we discuss Hubert’s background, how he moved into product management, his career at Good Data, where he was the VP of Product, and his decision to leave Good and start ProductBoard.

This post is Part 1 of our interview, Part 2 is here.

Three things you can do today

As always, we like to give you actionable takeaways from our podcast episodes. The three ideas below come directly from the first part of our interview with Hubert.

  1. Get in the problem space, not the solution space. Immerse yourself and your team in the problem that needs to be solved. Then, don’t devote so much of your time to the design and the solution – that’s a job for designers and engineers. Your advice and review is valuable, but your focus should be articulating the problem, then giving the rest of your team space to solve it.
  2. Turn your company or tribal knowledge into a system. It’s valuable even before it’s perfect. Think about team knowledge, the captured information you have, as something that deserves a system of record. Hubert described how difficult it is to simply use your memory for this, especially when it’s more than just you on the team. Of course, you can take a look at Product Board, but as Hubert pointed out: the system matters less than simply getting something in place.
  3. Finding the problem is orders of magnitude more important than how efficiently you can create a solution. Although it’s hard and not very well-defined, the process and results of focusing on the problem first will save time and frustration for many cycles to come, and often result in better product performance. So spend time distilling the problem from every angle, and share that with the entire product team. It will act as a beacon of light to follow.

Thanks to Hubert!

Rob and I want to reiterate our thanks to Hubert for participating in our new podcast as our first interview! If you want to learn more about ProductBoard, you can visit productboard.com. You can follow Hubert on Twitter at @hpalan, and ProductBoard tweets at @productboard.

As always, we’d love to ask two small favors from you:

  • First, please subscribe to the podcast on iTunes, or wherever you get your podcasts. You can find the podcast directly on this feed.
  • Second, please rate the podcast on iTunes or “recommend” it on your podcast app.

Finally, we really appreciate getting your opinion, so we’d love to hear from you in the comments below, or via Twitter (@atrnota) and our Medium publication, All The Responsibility.


11
Dec 15

All The Responsibility None Of The Authority Podcast – Season 2 Is Here!

2015-10-06-14.09.42

My ATR-2100 Mic and Mac laptop – where the magic happens!

It’s been just over a year since I started All The Responsibility, None Of The Authority, the podcast for product managers, product marketers, innovators, and entrepreneurs who want to be more effective and more successful creating and selling products.

I published a total of eight podcast episodes – not terrible, considering that most podcasts end on or before their seventh episode. So I beat the point spread!

And those were pretty meaty episodes – about product management systems of record, about the business value of product management, about a new way to think about product “requirements.” But for the second year of the podcast we’ll be a little more ambitious and get a lot more content out than the first year. Of course, still with the meatiness, the immediate applicability, and the powerful new ideas. So we’ve relaunched the podcast for Season 2. I say “we” because I’m joined by a new host! Rob McGrorty, product guy at Webgility in San Francisco, and an all around cool dude.

The other big change is a new website to host the podcast, along with a new podcast feed. The first three episodes are now up on our new site, http://alltheresponsibility.com. You’re reading this because I will crosspost new episodes to this site – and this feed which you’re listening to – as well. If you’re an existing subscriber you don’t need to do anything to get the new season with me and Rob. So you can keep your subscription here, or if you like, get the new feed from alltheresponsibility.com.

As always, we have our “three things you can start doing today to put these ideas into practice.” We want to give you concrete actions you can take from each of our episodes, which is a great savings in your cognitive capacity. (We’ll be doing a podcast on cognitive capacity and its implications for product managers later in the season.)

Let’s get on with the new season! This is the short introductory episode, introducing Rob. And there are two more episodes following that, a very interesting two-part interview with someone I think is solving a very big problem for us product managers, as you’ll hear.

And since today’s episode is “introduce the new season,” and this podcast help you become a better, more effective product person, the three things are focused on making sure you get every episode, and that every episode is as full of actionable content as possible.

  1. Sign up for our mailing list on http://alltheresponsibility.com. You can also easily subscribe to the podcast at alltheresponsibility.com/itunes, which definitely will give you insights on how to be a better product manager
  2. Write us a note in the comments, a tweet (@atrnota), an email, or leave us a voice message on the website with your ideas for what we should cover and whose insights you want to hear (that is, people we can interview). Let us know, good or bad, what we’re doing right and what we’re doing wrong.
  3. Give us a rating on iTunes, tweet about the podcast, or otherwise share your thoughts and – hopefully – recommendation on this podcast with your tribe. The better everyone gets as product managers, the better off we all are.

28
Oct 15

How To Share A Roadmap Without Driving Into A Ditch

A winding road (CC BY-NC-ND 2.0
Massimo Marino)

Roadmap-related conversations exploded on various social media channels a few weeks ago. Jared Spool put up a post on Medium about a concept he learned from Bruce McCarthy – basing roadmaps on themes rather than features. (Although product managers have known this concept for a long time.) And Marty Cagan responded to the Jared Spool post with one of his own. Of course, product managers have written about roadmaps – and been on the ground making roadmaps – for a long time.

But a question on the PMHQ Slack channel piqued my interest most particularly. Someone asked: “What do you use for roadmapping?” The questioner turned out to be someone from outside the high tech/software space. She wondered how we managed our roadmaps in high tech and software.

I used the question as the springboard for a riff on the PM HQ chat board.

My attitude toward “roadmaps” and “roadmapping” for products is perhaps iconoclastic. And apparently idiosyncratic. But I hope the following practical advice will help you navigate the quicksand of roadmaps. Especially when you have to share with people external to the product organization.

What Is A Roadmap?

A common question when PMs get together is “what do you use for roadmapping?” This question can mean lots of things, but usually it means one of two:

  1. How do you manage the list of features that you expect your developers to work on over the next period?
  2. How do you present the list of features you are developing to outside stakeholders? Such as executives, other internal organizations, customers, or analysts.

Personally, I usually call #1 “the plan” rather than the roadmap.

If I’m going to share a roadmap with anyone other than dev, I make it in PowerPoint. I never want to put a) real or b) all the information in something I’m sharing externally. Not even to other people in the company, normally.

By “real” I mean “with all warts exposed.” For example, our internal plans use insider technical terms. Those depend on understanding our technology (not just the product). I don’t want to require or expect my stakeholders to make that leap.

I always sanitize what gets shared with others. And then I also move it “up a level” – or four.

When presenting a roadmap externally, I always show themes or “epics,” rather than features. I often present them as happening over a time period different from their actual schedule. If there interesting interim releases, I might show those as well.

There are quite a few constraints when putting these epics onto the roadmap. Usually I want them to be one or two words, maybe three. They need to be in non-technical language, and not domain specific. Often one box or epic on the roadmap will represent many “epics” or “features” or “chunks of value.” In our real plan, they are on their own schedules. Sometimes I separate out features that are part of the same epic because they help me tell a better story. For example, if I’m presenting to a customer who requested a specific feature, I might highlight it.

And if possible I don’t even give people that roadmap, the cleaned up one, I only present it to them. (This is often not possible.)

For example, my team’s current feature is “Staffing Requests Phase 4 – Replan/Route-To enhancements.” It’s an epic. But while it’s a meaningful name for the product org, it’s a terrible name to expose to outsiders. It would raise many more questions than it answered. So, for a customer, it’s called “Resource Management” or “Centralized Staffing.” And as such it’s combined with some other related epics that I also don’t mention. This combination of epics is a theme.

I also often will prune things off the roadmap for particular audiences. For example, if I know they don’t want some capability, I might not mention it. Or if I’m worried they’ll think it’s distracting us from their favorite thing. Or, to emphasize they are not our only customer, I might highlight a feature they don’t care about.

Roadmap Tools

There are many tools that position themselves as “roadmap tools” for product managers. Usually these are really about the first meaning I listed above – “the plan.” They aren’t oriented to “how do I present what I’m working on to stakeholders.”

In my ideal product management tool, I could make a roadmap I could actually share with stakeholders. It would start by supporting “public names” for features and themes. It would have the ability to buffer the expected delivery dates. I could edit, annotate, or hide any entries I wished. And it would put all that into a PowerPoint slide that I could load into a deck and update in real time. This is not a trivial set of things to support.

Software Is Different

The original question was from a software industry outsider. I thought it would be useful to compare software roadmaps with those of other industries. The first takeaway? Comparing a software company’s roadmap to a roadmap from another industry is apples to oranges.

Usually those other types of companies have products that obey the laws of physics, such as semiconductor makers or car manufacturers.

Conversely, software company roadmaps often present capabilities that are not even designed, much less built.

Here’s a thought experiment for you. How soon before they hit the showroom do carmakers release information about the features and capabilities of their next car models? It’s about a year if you think about it. How long does it take to get a new car feature that’s designed and developed for manufacturing to the showroom floor? The answer: about a year. When carmakers announce new features on cars, what they call their roadmap, they’ve already done all the design and development work on those features. They are not predicting the future.

How about semiconductors? Intel has a 1-2 year roadmap for its processors. How long does it take for a new semiconductor fabrication innovation to get from discovery and validation in the lab to being an actual feature on a chip that you can buy? Well, it’s about three years. Intel’s two-year roadmap is not predicting the future – they know and have proven the technology.

And even then the roadmap slips. Back in May of 2015, Intel said it would ship 10nm chips in calendar 2015. By July its roadmap had changed, with the 10nm chips pushed back to 2016.

Take action

Here are three things you can do today to improve the roadmaps you share with external people.

  1. Focus your roadmap on themes, not features.
  2. Use customer language in your roadmap, not technical or insider jargon.
  3. Make sure you understand the desires, needs, requests, and pains of the stakeholders to whom you are presenting, so you can fit your presentation to their expectations.

How do you use roadmaps?

Do you have techniques for sharing the future for your external stakeholders? Do you have stories about how you finessed a difficult situation? Or have you accidentally set their expectations that you would deliver something impossible?


24
Apr 14

More On The Path Between Great Idea and Successful Product

Aeropress coffee maker (photo my m15u, CC2.0 licensed)

More on what it takes to turn a great idea into a great product, this time from the inventor of the Aerobie flying ring. Steve Jobs said “there’s a tremendous amount of craftsmanship between a having a great idea and having a great product,” but it’s not just craftsmanship – there are obstacles of all kinds, as Adler experienced both with the Aerobie and the Aeropress coffee maker.

At every turn, the AeroPress — like most of Adler’s other inventions — encountered innumerable roadblocks, faced skepticism, and was doubted. Like anyone who has forged new ground, Adler had a choice at each junction: throw in the towel, or return to the drawing board; he consistently chose the latter. In many ways, the AeroPress is a reflection of its inventor: it’s simple, but precise, it’s highly adaptable, and it squeezes every last drop of flavor from the bean.

Link: The Invention of the AeroPress

Hattip to Boing Boing for the link and to Zachery Crockett of Pricenomics for the fascinating Adler article.


22
Apr 14

The Distance Between A Great Idea and “An Elegant, Really Beautiful Solution That Works”

An elegant handmade tool for making elegant handmade furniture (photo by Visitflanders, CC 2.0 licensed)

One of the things that really hurt Apple was after I left, John Sculley got a very serious disease. And that disease—I’ve seen other people get it, too—it’s the disease of thinking that a having a great idea is really 90 percent of the work. And if you just tell people, ‘here’s this great idea,’ then of course they can go off and make it happen. The problem with that is that there’s a tremendous amount of craftsmanship between a having a great idea and having a great product. (Steve Jobs, 1995)

The good stuff in product management happens when new concepts start to emerge as you work, based on or sparked from other ideas bashing together, and human insight, and touch and feel and a sense of elegance. Where the whole is much more than the sum of its parts.

Unfortunately, lots of people think of product management as if simply having an idea is the hard part, and turning that idea into a product is just a simple process of A-to-B. Partly because that’s what they’ve experienced with other business processes, which are mostly just complicated – lots of moving parts, but fitting together in a well-understood way. This is not how good products arise – things that seem obvious at first turn out not to be, while things that seem hard at first often end up simple. Jobs understood this better than anyone, and he said so often.

When you start looking at a problem and it seems really simple, you don’t really understand the complexity of the problem. Then you get into the problem, and you see that it’s really complicated, and you come up with all these convoluted solutions. That’s sort of the middle, and that’s where most people stop… But the really great person will keep on going and find the key, the underlying principle of the problem – and come up with an elegant, really beautiful solution that works. (Steve Jobs again.)

I’m inspired every time I read this quote.

Mailing List Signup

Sign up for my mailing list to make sure you don’t miss any of my posts!


09
Apr 14

Structured Vs. Unstructured – What PMs Can Learn From Mozart

Don’t be like this guy! (Image by Christina, CC 2.0 licensed)

There’s always a balance between structure and lack of structure. It plays out in every domain, and especially every creative domain. Structure can help us think, can help us remember (i.e., be an offboard memory), and can give us guidelines within which to be creative.

Consider the classical composers – Bach, Mozart, Beethoven – each had a structure in which they composed, and part of their greatness was creating the greatest of works in that structure. The other part of their genius was in breaking the rules of those structures and extending the structures to accommodate new thinking and new avenues for creativity. We might not have had a Beethoven if Mozart had said “let there be no rules for music anymore!”

But, on the other hand, we wouldn’t have had a Beethoven if Mozart had only followed the rules he got from Bach. Breaking the rules, even while mostly playing within them, characterizes most important creative work across history. Even transgressive artists start from a structure – in fact, their transgression is only meaningful in opposition to the structure it transgresses.

The point is, some structure – the right structure – is good. History has shown that it’s better to have structure, but to break out of its rules sometimes, than to have no structure. ([tweetthis hidden_hashtags=”#prodmgmt”]It’s better to have structure but break the rules sometimes, than to have no structure.[/tweetthis]) And as the Heath Brothers discuss beautifully and at length in Decisive, you have to break your structure sometimes to enable creativity.

You have to strike a balance. Most tools “designed for” PMs are too constricting (see my earlier post on the danger of treating product management as a list management problem). But in contrast wikis are too freeform – they don’t help you think as a product manager, but just as a thinker. Without enough structure, it’s easier to leave stuff out of your thinking that you should be including (see my post about Impact Areas, for example). This is even more true if you want some analytical ability – analytics depends on structure.

Let me know what you think about structure and lack of structure in the comments.

Mailing List Signup

Sign up for my mailing list to make sure you don’t miss any of my posts!


05
Mar 14

“Creating Value” Means Eliminating A Problem Completely, Not Making It 5% Better

If your goal is to create value in the world with your product or offering, then you need to make sure your product either:

We all get these credit card offers in the mail every week. The people sending those direct mail offers are doing their best to send fewer and fewer, and have more and more of the recipients actually take the offers. But the numbers are pathetic. A great response to one of those come-ons is that 2% turn into customers after three impressions. That means that for every customer I get, I had to send out 150 of those mailers. And the 49 people who got three different offers are pissed off at me. And a giant pile of paper needs to go into the landfill. And that’s for an offer that performs well – if an offer performs badly it might be ten times as many mailings for the same result – one customer.

If you are sending out credit card offers, you can get marketing software today that might help you increase that 2% response rate slightly. Say to 2.1%. That’s a big enough increase that if you send the offers to enough people you’ll make a measurable amount more money. But I have to ask – is that marketing software helping you create value? Or is it just extracting value?

What if you had marketing software that could ensure your ad will only appear for people who will buy your thing. If a person won’t buy it, they won’t see the ad. That would be a gamechanger in the marketing world. It changes marketing software from a tool for extracting value to a tool for creating value, by ensuring the people who need your product hear about it, while those who don’t care aren’t bothered.

I don’t want to pick on marketing software – it’s just an easy target. But there are a lot of enterprise software companies out there whose value proposition is “we will make you 20% more effective” (or 5%, as in my example). Most consumer software companies have the same message. But I’m interested in products and processes that will make a problem go away completely.

That might be a fantasy for marketing software, given human nature, but there are examples where it’s happened. That’s what the Toyota Production System did in the 70’s and 80’s for example. Toyotas went from having a slightly-worse than industry standard level of defects in their car to essentially zero defects. That changed the company, the industry, and consumers’ expectations. And as a result, it created a huge amount of value in the world.

The iPod, in its own way, made a problem go away completely. In the days of the Walkman it was always a challenge – “Which tapes should I take with me so I will always have music I want?” When the iPod came out you could put all your music on it. Problem gone.

Generally, a new product is not worth the cost of changing if it doesn’t improve the process (at least some part of it) by an order of magnitude, or completely eliminate a problem. That’s where you really start to create value in the world, instead of just extracting it.