Posts Tagged ‘Product Development Engine’
There are a number of models to increase the probability of success of new work. One well known approach is the VC model where multiple projects are run in parallel. The trick is to start projects with the potential to deliver ultra-high returns. The idea isn’t to minimize the investment but to place multiple bets. When money’s tight, the VC model is not your friend.
Another method to increase the probability of success is to increase the learning rate. The best known method is the Lean Startup method. Come up with an idea, build a rough prototype, show it to potential customers and refine or pivot. The process is repeated until a winning concept finds a previously unknown market segment and the money falls from the sky. In a way, it’s like the VC Model, but it’s not a collection of projects run in parallel, it’s a sequential series of high return adventures punctuated by pivots. The Lean Startup is also quite good when money’s tight. A shoe string budget fosters radical learning strategies and creates focus which are both good ideas when coffers are low.
And then there’s the VC/Lean Startup combo. A set of high potential projects run in parallel, each using Lean’s build, show, refine method to learn at light speed. This is not the approach for empty pockets, but it’s a nice way to test game changing ideas quickly and efficiently.
Things are different when you try to do an innovation project within a successful company. Because the company is successful, all resources are highly utilized, if not triple-booked. On the balance sheet there’s plenty of money, but practically the well is dry. The organization is full up with ROI-based projects that will deliver marginal (but predictable) top line growth, and resources are tightly shackled to their projects. Though there’s money in the bank, it feels like the account is over drawn. And with this situation there’s a unique and expensive failure mode lurking in the shallows.
The front end of innovation work is resource light. New prototypes are created quickly and inexpensively and learning is fast and cheap. Though the people doing the work are usually highly skilled and highly valuable, it doesn’t take a lot of people to create a functional prototype and test it with new customers. And then, when the customers love it and it’s time to commercialize, there’s no one home. No one to do the work. And, unlike the relatively resource light front end work, commercialization work is resource heavy and expensive. The failure mode – the successful front end work is nothing but pure waste. All the expense of creativity with none of innovation’s return. And more painful, if the front end was successful the potential failure mode was destined to happen. There was no one to pick it up from the start.
The least expensive projects are the ones that never start. Before starting a project, ask “What if it works?”
image credit – jumping lab
The past has past, never to come again. But if you tell yourself old stories the past is still with you. If you hold onto your past it colors what you see, shapes what you think and silently governs what you do. Not skillful, not helpful. Old stories are old because things have changed. The old plays won’t work. The rules are different, the players are different, the situation is different. And you are different, unless you hold onto the past.
As a tactic we hold onto the past because of aversion to what’s going on around us. Like an ostrich we bury our head in the sands of the past to protect ourselves from unpleasant weather buffeting us in the now. But there’s no protection. Grasping tightly to the past does nothing more than stop us in our tracks.
If you grasp too tightly to tired technology it’s game over. And it’s the same with your tired business model – grasp too tightly and get run through by an upstart. But for someone who wants to make a meaningful difference, what are the two things that are sacred? The successful technology and successful business model.
It’s difficult for an organization to decide if the successful technology should be reused or replaced. The easy decision is to reuse it. New products come faster, fewer resources are needed because the hard engineering work has been done and the technical and execution risks are lower. The difficult decision is to scrap the old and develop the new. The smart decision is to do both. Launch products with the old technology while working feverishly to obsolete it. These days the half-life of technology is short. It’s always the right time to develop new technology.
The business model is even more difficult to scrap. It cuts across every team and every function. It’s how the company did its work. It’s how the company made its name. It’s how the company made its money. It’s how families paid their mortgages. It’s grasping to the past success of the business model that makes it almost impossible to obsolete.
People grasp onto the past for protection and companies are nothing more than a loosely connected network of people systems. And these people systems have a shared past and a good memory. It’s no wonder why old technologies and business models stick around longer than they should.
To let go of the past people must see things as they are. That’s a slow process that starts with a clear-eyed assessment today’s landscapes. Make maps of the worldwide competitive landscape, intellectual property, worldwide regulatory legislation, emergent technologies (search YouTube) and the sea of crazy business models enabled by the cloud.
The best time to start the landscape analyses was two years ago, but the next best time to start is right now. Don’t wait.
Image credit – John Fife
In high school we got too comfortable with partial credit. Start the problem the right way, make a few little mistakes and don’t actually finish the problem – 50% credit. With product development, and other real life projects, there’s no partial credit. A project that’s 90% done is worth nothing. All the expense with none of the benefit. Don’t launch, don’t sell. No finish, no credit.
But our ill-informed focus on productivity has hobbled us. Because we think running projects in parallel is highly efficient, we start too many projects. This glut does nothing more than slow down all the other projects in the pipeline. It’s like we think queuing theory isn’t real because we don’t understand it. But to be fair to queuing and our stockholders, queuing theory is real.
Queues are nothing more than a collection of wayward travelers waiting in line for a shared resource. Wait in line for fast food, you’re part of a queue. Wait in line for a bank teller (a resource,) you’re queued up. Wait in line to board a plane, you’re waiting in a queue. But the name isn’t important. Line or queue, what matters is how long you wait.
Lines are queues and queues are lines, but the math behind them is funky. From firsthand experience we know longer queues mean longer wait times. And if the cashier isn’t all that busy (in queuing language – the utilization of the resource is low) the wait time isn’t all that bad and it increases linearly with the number of people (or jobs) in the queue. When the shared resource (cashier) isn’t highly utilized (not all that busy), add a few more shoppers per hour and wait times increase proportionately. But, and this is a big but, if the resource busy more than 80% of the time, increasing the number of shoppers increases the wait time astronomically (or exponentially.) When shoppers arrive in front of the cashier just a bit more often, wait times can double or triple or more.
For wait times, the math of queueing theory says one plus one equals two and one plus one plus one equals seven. Wait times increase linearly right up until they explode. And when wait times explode, projects screech to a halt. And because there’s no partial credit, it’s a parking lot of projects without any of the profit. And what’s the worst thing to do when projects aren’t finishing quickly enough? Start more projects. And what do we do when projects aren’t launching quickly enough? Start more projects.
When there’s no partial credit, instead of efficiency it’s better to focus on effectiveness. Instead of counting the number of projects running in parallel (efficiency,) count the number of projects that have finished (effectiveness.) To keep wait times reasonable, fiercely limit the amount of projects in the system. And there’s a simple way to do that. Figure out the sweet spot for your system, say, three projects in parallel, and create three project “tickets.” Give one ticket to the three active projects and when the project finishes, the project ticket gets assigned to the next project so it can start. No project can start without a ticket. No ticket, no project.
This simple ticket system caps the projects, or work in process (WIP,) so shared resources are utilized below 80% and wait times are low. Projects will sprint through their milestones and finish faster than ever.
By starting fewer projects you’ll finish more. Stop starting and start finishing.
Image credit – Fred Moore
For established companies, when times are good, it’s not the right time to try something new – the resources are there but the motivation is not; and when times are tough it’s also the wrong time to try something new – the motivation is there but the breathing room is not. There are an infinite number of scenarios, but for the established company it’s never a good time to try something new.
For startup companies, when times are good, it’s the right time to try something new – the resources are there and so is the motivation; and when times are tough it’s also the right time to try something new – the motivation is there and breathing room is a sign of weakness. Again, the scenarios are infinite, but for the startup is always a good time to try something new.
But this is not a binary world. To create new markets and new customers, established companies must be a little bit startup, and to scale, startups must ultimately be a little bit established. This ambidextrous company is good on paper, but in the trenches it gets challenging. (Read Ralph Ohr for an expert treatment.) The establishment regime never wants to do anything new and the startup regime always wants to. There’s no middle ground – both factions judge each other through jaded lenses of ROI and learning rate and mutual misunderstanding carries the day. Trouble is, all companies need both – established companies need new markets and startups need to scale. But it’s more complicated than that.
As a company matures the balance of power should move from startup to established. But this tricky because the one thing power doesn’t like to do is move from one camp to another. This is the reason for the “perpetual startup” and this is why it’s difficult to scale. As the established company gets long in the tooth the balance of power should move from the establishment to the startup. But, again, power doesn’t like to change teams, and established companies squelch their fledgling startup work. But it’s more complicated, still.
The competition is ever-improving, the economy is ever-changing and the planet is ever-warming. New technologies come on-line, and new business models test the waters. Some work, some don’t. Huge companies buy startups just to snuff them out and established companies go away. The environment is ever-changing on all fronts. And the impermanence pushes and pulls on the pendulum of power dynamics.
All companies want predictability, but they’ll never have it. All growth models are built on rearward-looking fundamentals and forward-looking conjecture. Companies will always have the comfort of their invalid models, but will never the predictability they so desperately want. Instead of predictability, companies would be better served by a strong sense of how it wants to go about its business and overpowering genetics of adaptability.
For a strong definition of how to go about business, a simple declaration does nicely. “We want to spend 80% of our resources on established-company work and 20% on startup-company work.” (Or 90-10, or 95-5.) And each quarter, the company measures itself against its charter, and small changes are made to keep things on track. Unless, of course, if the environment changes or the business model runs out of gas. And then the company adapts. It changes its approach and it’s projects to achieve its declared 80-20 charter, or, changes the charter altogether.
A strong charter and adaptability don’t seem like good partners, but they are. The charter brings focus and adaptability brings the change necessary to survive in an every-changing environment. It’s not easy, but it’s effective. As long as you have the right leaders.
Image credit – Rick Abraham1
When doing something from the first time you’re going to get it wrong. There’s no shame in that because that’s how it goes with new work. But more strongly, if you don’t get it wrong you’re not trying hard enough. And more strongly, embrace the inherent wrongness as a guiding principle.
Take Small Bites. With new work, a small scope is better than a large one. But it’s exciting to do new work and there’s a desire to deliver as much novel usefulness as possible. And, without realizing it, the excitement can lead to a project bloated with novelty. With the best intentions, the project team is underwater with too much work and too little time. With new work, it’s better to take one bite and swallow than three and choke.
Ratchet Thinking. With new work comes passion and energy. And though the twins can be helpful and fun to have around, they’re not always well-behaved. Passion can push a project forward but can also push it off a cliff. Energy creates pace and can quickly accelerate a project though the milestones, but energy can be careless and can just as easily accelerate a project in the wrong direction. And that’s where ratchet thinking can help.
As an approach, the objective of ratchet thinking is to create small movements in the right direction without the possibility of back-sliding. Solve a problem and click forward one notch; solve a second problem and click forward another notch. But, with ratchet thinking, if the third problem isn’t solved, the project holds its ground at the second notch. It takes a bit more time to choose the right problem and to solve it in a way that cannot unwind progress, but ultimately it’s faster. Ratchet thinking takes the right small bite, chews, swallows.
Zero Cost of Change. New work is all about adding new functions, enhancing features and fixing what’s broken. In other words, new work is all about change. And the faster change can happen, the faster the product/service/business model is ready for sale. But as the cost of change increases the rate of changes slows. So why not design the project to eliminate the cost of change?
To do that, design the hardware with a bit more capability and headroom so there’s some wiggle room to handle the changes that will come. Use a modular approach for the software to minimize the interactions of software changes and make sure the software can be updated remotely without customer involvement. And put in place a good revision control (and tracking) mechanism.
Doing new work is full of contradictions: move quickly, but take the time to think things through; take on as much as you can, but no more; be wrong, but in the right way; and sometimes slower is faster.
But doing new work you must.
image credit – leasqueaky
Two words to live by: Critical Path.
By definition, the next task to work on is the next task on the critical path. How do you tell if the task is on the critical path? When you are late by one day on a critical path task, the project, as a whole, will finish a day late. If you are late by one day and the project won’t be delayed, the task is not on the critical path and you shouldn’t work on it.
Rule 1: If you can’t work the critical path, don’t work on anything.
Working on a non-critical path task is worse than working on nothing. Working on a non-critical path task is like waiting with perspiration. It’s worse than activity without progress. Resources are consumed on unnecessary tasks and the resulting work creates extra constraints on future work, all in the name of leveraging the work you shouldn’t have done in the first place.
How to spot the critical path? If a similar project has been done before, ask the project manager what the critical path was for that project. Then listen, because that’s the critical path. If your project is similar to a previous project except with some incremental newness, the newness is on the critical path.
Rule 2: Newness, by definition, is on the critical path.
But as the level of newness increases, it’s more difficult for project managers to tell the critical path from work that should wait. If you’re the right project manager, even for projects with significant newness, you are able to feel the critical path in your chest. When you’re the right project manager, you can walk through the cubicles and your body is drawn to the critical path like a divining rod. When you’re the right project manager and someone in another building is late on their critical path task, you somehow unknowingly end up getting a haircut at the same time and offering them the resources they need to get back on track. When you’re the right project manager, the universe notifies you when the critical path has gone critical.
Rule 3: The only way to be the right project manager is to run a lot of projects and read a lot. (I prefer historical fiction and biographies.)
Not all newness is created equal. If the project won’t launch unless the newness is wrestled to the ground, that’s level 5 newness. Stop everything, clear the decks, and get after it until it succumbs to your diligence. If the product won’t sell without the newness, that’s level 5 and you should behave accordingly. If the newness causes the product to cost a bit more than expected, but the project will still sell like nobody’s business, that’s level 2. Launch it and cost reduce it later. If no one will notice if the newness doesn’t make it into the product, that’s level 0 newness. (Actually, it’s not newness at all, it’s unneeded complexity.) Don’t put in the product and don’t bother telling anyone.
Rule 4: The newness you’re afraid of isn’t the newness you should be afraid of.
A good project plan starts with a good understanding of the newness. Then, the right project work is defined to make sure the newness gets the attention it deserves. The problem isn’t the newness you know, the problem is the unknown consequence of newness as it ripples through the commercialization engine. New product functionality gets engineering attention until it’s run to ground. But what if the newness ripples into new materials that can’t be made or new assembly methods that don’t exist? What if the new materials are banned substances? What if your multi-million dollar test stations don’t have the capability to accommodate the new functionality? What if the value proposition is new and your sales team doesn’t know how to sell it? What if the newness requires a new distribution channel you don’t have? What if your service organization doesn’t have the ability to diagnose a failure of the new newness?
Rule 5: The only way to develop the capability to handle newness is to pair a soon-to-be great project manager with an already great project manager.
It may sound like an inefficient way to solve the problem, but pairing the two project managers is a lot more efficient than letting a soon-to-be great project manager crash and burn. After an inexperienced project manager runs a project into the ground, what’s the first thing you do? You bring in a great project manager to get the project back on track and keep them in the saddle until the product launches. Why not assume the wheels will fall off unless you put a pro alongside the high potential talent?
Rule 6: When your best project managers tell you they need resources, give them what they ask for.
If you want to deliver new value to new customs there’s no better way than to develop good project managers. A good project manager instinctively knows the critical path; they know how the work is done; they know to unwind situations that needs to be unwound; they have the personal relationships to get things done when no one else can; because they are trusted, they can get people to bend (and sometimes break) the rules and feel good doing it; and they know what they need to successfully launch the product.
If you don’t know your critical path, you don’t know very much. And if your project managers don’t know the critical path, you should stop what you’re doing, pull hard on the emergency break with both hands and don’t release it until you know they know.
Image credit – Patrick Emerson
One of the best ways to improve your brand is to improve your products. The most common way is to provide more goodness for less cost – think miles per gallon. Usually it’s a straightforward battle between market leaders, where one claims quantifiable benefit over the other – Ours gets 40 mpg and theirs doesn’t. And the numbers are tied to fully defined test protocols and testing agencies to bolster credibility. Here’s the data. Buy ours
But there’s a more powerful way to improve your brand, and that’s to map your products to reliability. It’s far a more difficult game than the quantified head-to-head comparison of fuel economy and it’s a longer play, but done right, it’s a lasting play that is difficult to beat. Run the thought experiment: think about the brands you associate with reliability. The brands that come to mind are strong, lasting brands, brands with staying power, brands whose products you want to buy, brands you don’t want to compete against. When you buy their products you know what you’re going to get. Your friends tell you stories about their products.
There’s a complete a complete tool set to create products that map to reliability, and they work. But to work them, the commercialization team has to have the right mindset. The team must have the patience to formally define how all the systems work and how they interact. (Sounds easy, but it can be painfully time consuming and the level of detail is excruciatingly extreme.) And they have to be willing to work through the discomfort or developing a common understanding how things actually work. (Sounds like this shouldn’t be an issue, but it is – at the start, everyone has a different idea on how the system works.) But more importantly, they’ve got to get over the natural tendency to blame the customer for using the product incorrectly and learn to design for unintended use.
The team has got to embrace the idea that the product must be designed for use in unpredictable ways in uncontrolled conditions. Where most teams want to narrow the inputs, this team designs for a wider range of inputs. Where it’s natural to tighten the inputs, this team designs the product to handle a broader set of inputs. Instead of assuming everything will work as intended, the team must assume things won’t work as intended (if at all) and redesign the product so it’s insensitive to things not going as planned. It’s strange, but the team has to design for hypothetical situations and potential problems. And more strangely, it’s not enough to design for potential problems the team knows about, they’ve got to design for potential problems they don’t know about. (That’s not a typo. The team must design for failure modes it doesn’t know about.)
How does a team design for failure modes it doesn’t know about? They build a computer-based behavioral model of the system, right down to the nuts, bolts and washers, and they create inputs that represent the environment around the system. They define what each element does and how it connects to the others in the system, capturing the governing physics and propagation paths of connections. Then they purposefully break the functions using various classes of failure types, run the analysis and review the potential causes. Or, in the reverse direction, the team perturbs the system’s elements with inputs and, as the inputs ripple through the design, they find previously unknown undesirable (harmful) functions.
Purposefully breaking the functions in known ways creates previously unknown potential failure causes. The physics-based characterization and the interconnection (interaction) of the system elements generate unpredicted potential failure causes that can be eliminated through design. In that way, the software model helps find potential failures the team did not know about. And, purposefully changing inputs to the system, again through the physics and interconnection of the elements, generates previously unknown harmful functions that can be designed out of the product.
If you care about the long-term staying power of your brand, you may want to take a look at TechScan, the software tool that makes all this possible.
Image credit — Chris Ford.
Agree or not, companies think they have to grow to survive. (I don’t believe it.) For companies of all sizes and shapes, growth is the single most important forcing function. Is has tidal wave power, and whether you’re a surfer, sailor or power-boater, it’s important to respect it. More than that, when push comes to shove, it’s the only wave in town.
Companies’ recipe for growth is simple: make more, sell more. And some keep it simpler: sell more.
The best growth: sell new products or provide new services to new customers; next best: sell new to the same customers; next next best: sell more of the same to the same customers. The last flavor is the easiest, right up until it isn’t. And once it isn’t, companies must come up with new things to sell. That works for a while, until it doesn’t. Then, and only then, after exhausting all other possibilities, companies must create real newness and try to sell it to strangers.
The model works well as long as everyone in the industry follows it. But when an up-start outsider enters the market back-to-front, the wheels fall off. When they develop useful newness before you and sell it to your customers (new customers for them), that’s not good. And that’s why it’s so important to start with different — right now.
To help your company do more work that’s different, start with an inventory of your novelty. Novel work is work that creates difference, and that difference can be defined only in comparison with the state-of-the-art (what is, or the baseline system). Start with a functional analysis of your state-of-the-art. Create a block diagram of your business model, your most successful product and the service that defines your brand. Take a look at your technology and new product development projects and flag the ones that will create things that aren’t on your three functional analyses. (Improvement projects, because they improve what is, cannot be flagged as novel.)
Put all your novelty on one page and decide if you like it. (No way around it, how you respond to the level and type of novelty in your quiver is a judgment call.) If you like what you see, keep going. If you don’t, stop some improvement projects and start some projects that create useful novelty. The stopping will not come easy. Existing projects have momentum and people have personal attachment to them. The only thing powerful enough to stop them is the all-powerful growth objective. If company leaders learn the existing projects won’t meet the growth objective, the tidal wave will sweep away some lesser projects to make room for new ones.
There will be great internal pressure to add projects without stopping some, but that won’t work. Everyone is fully booked and can’t deliver on additional projects even if you tell them to. If you’re not willing to stop projects, you’re better off staying the course and waiting until you finish one before you start a project to increase your novelty score.
Novelty is good because there’s more upside potential, and improvement is good because there’s more certainty. One is not better than the other. You need both.
In the end, you’re going to have to judge if you’re happy with what you’ve got. That’s a difficult task that no one can make easier for you. But it is possible to use your judgment better. If you can clearly call out what’s novel and what’s not, you’re on your way.
Image credit – s3aphotography (image cropped)
Hands-on versus hands-off – as a leader it’s a fundamental choice. And for me the single most important guiding principle is – do what it takes to maintain or strengthen the team’s personal ownership of the work.
If things are going well, keep your hands off. This reinforces the team’s ownership and your trust in them. But it’s not hands-off in and ignore them sense; it’s hands-off in a don’t tell them what to do sense. Walk around, touch base and check in to show interest in the work and avoid interrogation-based methods that undermine your confidence in them. This is not to say a hands-off leader only superficially knows what’s going on, it should only look like the leader has a superficial understanding.
The hands-off approach requires a deep understanding of the work and the people doing it. The hands-off leader must make the time to know the GPS coordinates of the project and then do reconnaissance work to identify the positions of the quagmires and quicksand that lay ahead. The hands-off leader waits patiently just in front of the obstacles and makes no course correction if the team can successfully navigate the gauntlet. But when the team is about to sink to their waists, leader gently nudges so they skirt the dangerous territory.
Unless, of course, the team needs some learning. And in that case, the leader lets the team march it’s project into the mud. If they need just a bit of learning the leader lets them get a little muddy; and if the team needs deep learning, the leader lets them sink to their necks. Either way, the leader is waiting under cover as they approach the impending snafu and is right beside them to pull them out. But to the team, the hands-off leader is not out in front scouting the new territory. To them, the hands-off leader doesn’t pay all that much attention. To the team, it’s just a coincidence the leader happens to attend the project meeting at a pivotal time and they don’t even recognize when the leader subtly plants the idea that lets the team pull themselves out of the mud.
If after three or four near-drowning incidents the team does not learn or change it’s behavior, it’s time for the hands-off approach to look and feel more hands-on. The leader calls a special meeting where the team presents the status of the project and grounds the project in the now. Then, with everyone on the same page the leader facilitates a process where the next bit of work is defined in excruciating detail. What is the next learning objective? What is the test plan? What will be measured? How will it be measured? How will the data be presented? If the tests go as planned, what will you know? What won’t you know? How will you use the knowledge to inform the next experiments? When will we get together to review the test results and your go-forward recommendations?
By intent, this tightening down does not go unnoticed. The next bit of work is well defined and everyone is clear how and when the work will be completed and when the team will report back with the results. The leader reverts back to hands-off until the band gets back together to review the results where it’s back to hands-on. It’s the leader’s judgement on how many rounds of hands-on roulette the team needs, but the fun continues until the team’s behavior changes or the project ends in success.
For me, leadership is always hands-on, but it’s hands-on that looks like hands-off. This way the team gets the right guidance and maintains ownership. And as long as things are going well this is a good way to go. But sometimes the team needs to know you are right there in the trenches with them, and then it’s time for hands-on to look like hands-on. Either way, its vital the team knows they own the project.
There are no schools that teach this. The only way to learn is to jump in with both feet and take an active role in the most important projects.
Image credit – Kerri Lee Smith
When it’s time for a tough decision, it’s time to use data. The idea is the data removes biases and opinions so the decision is grounded in the fundamentals. But using the right data the right way takes a lot of disciple and care.
The most straightforward decision is a decision between two things – an either or – and here’s how it goes.
The first step is to agree on the test protocols and measure systems used to create the data. To eliminate biases, this is done before any testing. The test protocols are the actual procedural steps to run the tests and are revision controlled documents. The measurement systems are also fully defined. This includes the make and model of the machine/hardware, full definition of the fixtures and supporting equipment, and a measurement protocol (the steps to do the measurements).
The next step is to create the charts and graphs used to present the data. (Again, this is done before any testing.) The simplest and best is the bar chart – with one bar for A and one bar for B. But for all formats, the axes are labeled (including units), the test protocol is referenced (with its document number and revision letter), and the title is created. The title defines the type of test, important shared elements of the tested configurations and important input conditions. The title helps make sure the tested configurations are the same in the ways they should be. And to be doubly sure they’re the same, once the graph is populated with the actual test data, a small image of the tested configurations can be added next to each bar.
The configurations under test change over time, and it’s important to maintain linkage between the test data and the tested configuration. This can be accomplished with descriptive titles and formal revision numbers of the test configurations. When you choose design concept A over concept B but unknowingly use data from the wrong revisions it’s still a data-driven decision, it’s just wrong one.
But the most important problem to guard against is a mismatch between the tested configuration and the configuration used to create the cost estimate. To increase profit, test results want to increase and costs wants to decrease, and this natural pressure can create divergence between the tested and costed configurations. Test results predict how the configuration under test will perform in the field. The cost estimate predicts how much the costed configuration will cost. Though there’s strong desire to have the performance of one configuration and the cost of another, things don’t work that way. When you launch you’ll get the performance of AND cost of the configuration you launched. You might as well choose the configuration to launch using performance data and cost as a matched pair.
All this detail may feel like overkill, but it’s not because the consequences of getting it wrong can decimate profitability. Here’s why:
Profit = (price – cost) x volume.
Test results predict goodness, and goodness defines what the customer will pay (price) and how many they’ll buy (volume). And cost is cost. And when it comes to profit, if you make the right decision with the wrong data, the wheels fall off.
Image credit – alabaster crow photographic
For clarity on the innovative new product, here’s what the CEO needs.
Valuable Customer Outcomes – how the new product will be used. This is done with a one page, hand sketched document that shows the user using the new product in the new way. The tool of choice is a fat black permanent marker on an 81/2 x 11 sheet of paper in landscape orientation. The fat marker prohibits all but essential details and promotes clarity. The new features/functions/finish are sketched with a fat red marker. If it’s red, it’s new; and if you can’t sketch it, you don’t have it. That’s clarity.
The new value proposition – how the product will be sold. The marketing leader creates a one page sales sheet. If it can’t be sold with one page, there’s nothing worth selling. And if it can’t be drawn, there’s nothing there.
Customer classification – who will buy and use the new product. Using a two column table on a single page, these are their attributes to define: Where the customer calls home; their ability to pay; minimum performance threshold; infrastructure gaps; literacy/capability; sustainability concerns; regulatory concerns; culture/tastes.
Market classification – how will it fit in the market. Using a four column table on a single page, define: At Whose Expense (AWE) your success will come; why they’ll be angry; what the customer will throw way, recycle or replace; market classification – market share, grow the market, disrupt a market, create a new market.
For clarity on the creative work, here’s what the CEO needs: For each novel concept generated by the Innovation Burst Event (IBE), a single PowerPoint slide with a picture of its thinking prototype and a word description (limited to 12 words).
For clarity on the problems to be solved the CEO needs a one page, image-based definition of the problem, where the problem is shown to occur between only two elements, where the problem’s spacial location is defined, along with when the problem occurs.
For clarity on the viability of the new technology, the CEO needs to see performance data for the functional prototypes, with each performance parameter expressed as a bar graph on a single page along with a hyperlink to the robustness surrogate (test rig), test protocol, and images of the tested hardware.
For clarity on commercialization, the CEO should see the project in three phases – a front, a middle, and end. The front is defined by a one page project timeline, one page sales sheet, and one page sales goals. The middle is defined by performance data (bar graphs) for the alpha units which are hyperlinked to test protocols and tested hardware. For the end it’s the same as the middle, except for beta units, and includes process capability data and capacity readiness.
It’s not easy to put things on one page, but when it’s done well clarity skyrockets. And with improved clarity the right concepts are created, the right problems are solved, the right data is generated, and the right new product is launched.
And when clarity extends all the way to the CEO, resources are aligned, organizational confusion dissipates, and all elements of innovation work happen more smoothly.
Image credit – Kristina Alexanderson