How to run product innovation

Product innovation sounds bigger than it is. It means a new or improved product or service that is clearly different from what you already sell, and that a customer can actually use. Until someone outside the company can try it, you have meetings. You do not have a new product yet.

A lot of programs skip that. They pay for a lab, a strategy deck, and a feature list, and they call the missing customer “early.” The useful version is smaller. One offer. One person who can say no. One thing that has to be different. A date when you stop if the number is not there.

We will not take a brief that is only a vision. Spark is $750. You get a written answer: build it, change the idea, or do not do it. You keep that note. Invent is the build, after the page is clear. If you want six months of workshops with no end date, we are the wrong company.

A product, or a better way to work

If the only people who benefit are your own team, you are improving how the company works. That can be the better project. It is a different one. Hours, waste, and waiting belong there. Mixing the two gives you a tool nobody bought, and a product your own team will not use.

You can do both: a service you sell, and a better way to deliver it. Write them as two notes. The customer can turn down the product. You are the one who has to live with the internal change. Those are different reasons to stop.

What it means for a customer to use it

It means they can try it. A design file in a shared folder is not that. A simple login, on a job they already have, is enough to start. Keep it small. Do not leave it as an idea and still call it innovation.

Once they can say no, the rest is building. The company should own the code. If the software sends money or messages, a named person still approves it. The written scope should say what is not included. That is when the consulting should already be finished.

A page you can send this week

Write it the way you would explain it to a colleague. What are you selling, a product or a service a customer can use? Who is the real person who can try it and say no? What can they not do today? What date, and what number, would make you stop? What is the smallest version they can try this week? If it works, they should own the code. If it does not, you stop in writing.

If you do not know one of those answers, leave it blank. That blank is the useful part. Filling it with features is how a workshop takes the place of a product.

The sequence

Do these in order. Skip a line and you are back to a workshop.

1. 01

   Say what you are selling

   A product or a service a customer can buy and use. If the only people who gain from it are your own staff, you are improving how you work. That is a different project.

2. 02

   Name a real person

   Someone who can try it and say no. “Small businesses” is a group, not a person. If you cannot talk to them this month, you are still guessing.

3. 03

   Say what changes for them

   One thing they cannot do with what they have today. A longer list of features is not a change. Their week has to be different.

4. 04

   Decide when you will stop

   Pick a date and a number before anyone starts building. Paid orders, people coming back, or hours saved. “We will know when we see it” is how a project never ends.

5. 05

   Let them try something this week

   A simple version they can open and reject. A slide deck is an idea. A product is something they can use.

6. 06

   Then give them the keys

   If it works, the code, the design, and the admin access move to them when the last invoice is paid. If it does not work, you stop in writing.