Shipulski On Design

Archive for June, 2018

In business you’ve got to do two things: choose what to do and choose how to do it well.  I’m not sure which is more important, but I am sure there’s far more written on how to do things well and far less clarity around how to choose what to do.

Choosing what to do starts with understanding what’s being done now.  For technology, it’s defining the state-of-the-art. For the business model, it’s how the leading companies are interacting with customers and which functions they are outsourcing and which they are doing themselves. In neither case does what’s being done define your new recipe, but in both cases it’s the first step to figuring how you’ll differentiate over the competition.

Every observation of the state-of-the-art technologies and latest business models is a snapshot in time.  You know what’s happening at this instant, but you don’t know what things will look like in two years when you launch. And that’s not good enough. You’ve got to know the improvement trajectories; you’ve got to know if those trajectories will still hold true when you’ll launch your offering; and, if they’re out of gas, you’ve got to figure out the new improvement areas and their trajectories.

You’ve got to differentiate over the in-the-future competition who will constantly improve over the next two years, not the in-the-moment competition you see today.

For technology, first look at the competitions’ websites. For their latest product or service, figure out what they’re proud of, what they brag about, what line of goodness it offers.  For example, is it faster, smaller, lighter, more powerful or less expensive?  Then, look at the product it replaced and what it offered. If the old was faster than the one it replaced and the newest one was faster still, their next one will try to be faster.  But if the old one was faster than the one it replaced and the newest one is proud of something else, it’s likely they’ll try to give the next one more of that same something else.

And the rate of improvement gives another clue.  If the improvement is decreasing over time (old product to new product), it’s likely the next one will improve on a new line of goodness.  If it’s still accelerating, expect more of what they did last time.  Use the slope to estimate the magnitude of improvement two years from now.  That’s what you’ve got to be better than.

And with business models, make a Wardley Map.  On the map, place the elements of the business ecosystem (I hate that word) and connect the elements that interact with each other.  And now the tricky part.  Move to the right the mature elements (e.g., electrical power grid), move to the middle the immature elements (things that are clunky and you have to make yourself) and move to the middle the parts you can buy from others (products).  There’s a north-south element to the maps, but that’s for another time.

The business model is defined by which elements the company does itself, which it buys from others and which new ones they create in their labs.  So, make a model for each competitor.  You’ll be able to see their business model visually.

Now, which elements to work on?  Buy the ones you can buy (middle), improve the immature ones on the far left so they move toward the central region (product) and disrupt the lazy utilities (on the right) with some crazy technology development and create something new on the far left (get something running in the lab).

Choosing what to work on starts with Observation of what’s going on now. Then, that information is Oriented with analysis, synthesis and diverse perspective.  Then, using the best frameworks you know, a Decision is made.  And then, and only then, can you Act.

And there you have it.  The makings of an OODA loop-based methodology for choosing what to do.

For a great podcast on John Boyd, the father of the OODA loop, try this one.

And for the deepest dive on OODA (don’t start with this one) see Osinga – Science, Strategy and War.

One of the best ways to learn is to make a prototype.  Prototypes come in many shapes and sizes, but their defining element is the learning objective behind them.  When you start with what you want to learn, the prototype is sure to satisfy the learning objective.  But start with the prototype, and no one is quite sure what you’ll learn.  When prototypes come before the learning objective, prototypes are inefficient and ineffective.

Before staffing a big project, prototypes can be used to determine viability of the project.  And done right, viability prototypes can make for fast and effective learning.  Usually, the team wants to build a functional prototype of the product or service, but that’s money poorly spent until the business model is validated.   There’s nothing worse than building expensive prototypes and staffing a project, only to find the business model doesn’t hold water and no one buys the new thing you’re selling.

There’s no reason a business model can’t be validated with a simple prototype. (Think one-page sales tool.)  And there’s no reason it can’t be done at the earliest stages.  More strongly, the detailed work should be held hostage until the business model is validated.  And when it’s validated, you can feel good about the pot of gold at the end of the rainbow.  And if it’s invalidated, you saved a lot of time, money and embarrassment.

The best way to validate the business model is with a set of one-page documents that define for the customer what you will sell them, how you’ll sell it, how you’ll service it, how you’ll train them and how you’ll support them over the life of your offering.  And, don’t forget to tell them how much it will cost.

The worst way to validate the business model is buy building it.  All the learning happens after all the money has been spent.

For the business model prototypes there’s only one learning objective: We want to learn if the customer will buy what we’re selling.  For the business model to be viable, the offering has to hang together within the context of installation, service, support, training and price.  And the one-page prototype must call out specifics of each element.  If you use generalities like “we provide good service” or “our training plans are the best”, you’re faking it.

Don’t let yourself off the hook.  Use prototypes to determine the viability of the business model before spending the money to build it.

Image credit – Heather Katsoulis

To meet ever-increasing growth objectives, established companies want to be more entrepreneurial.  And the thinking goes like this – launch new products and services to create new markets, do it quickly and do it on a shoestring.  Do that Lean Startup thing.  Build minimum viable prototypes (MVPs), show them to customers, incorporate their feedback, make new MVPs, show them again, and then thoselaunch.

For software products, that may work well, largely because it takes little time to create MVPs, customers can try the products without meeting face-to-face and updating the code doesn’t take all that long.  But for products and services that require new hardware, actual hardware, it’s a different story.  New hardware takes a long time to invent, a long time to convert into an MVP, a long time to show customers and a long time to incorporate feedback.  Creating new hardware and launching quickly in an entrepreneurial way don’t belong in the same sentence, unless there’s no new hardware.

For hardware, don’t think smartphones, think autonomous cars.  And how’s that going for Google and the other software companies? As it turns out, it seems that designing hardware and software are different.  Yes, there’s a whole lot of software in there, but there’s also a whole lot of new sensor systems (hardware).  And, what complicates things further is that it’s all packed into an integrated system of subsystems where the hardware and software must cooperate to make the good things happen.  And, when the consequences of a failure are severe, it’s more important to work out the bugs.

And that’s the rub with entrepreneurship and an established brand.  For quick adoption, there’s strong desire to leverage the established brand – GM, Ford, BMW – but the output of the entrepreneurial work (new product or service) has to fit with the brand.  GM can’t launch something that’s half-baked with the promise to fix it later. Ford can come out with a new app that is clunky and communicates intermittently with their hardware (cars) because it will reflect poorly on all their products.  In short, they’ll sell fewer cars.  And BMW can’t come out with an entrepreneurial all-electric car that handles poorly and is slow off the start.  If they do, they’ll sell fewer cars.  If you’re an established company with an established brand, the output of your entrepreneurial work must fit with the established brand.

If you’re a software startup, launch it when it’s half-baked and fix it later, as long as no one will die when it flakes out.  And because it’s software, iterate early and often. And, there’s no need to worry about what it will do to the brand, because you haven’t created it yet.  But if you’re a hardware startup, be careful not to launch before it’s ready because you won’t be able to move quickly and you’ll be stuck with your entrepreneurial work for longer than you want.  Maybe, even long enough to sink the brand before it ever learned to swim.  Developing hardware is slow.  And developing robust hardware-software systems is far slower.

If you’re an established company with an established brand, tread lightly with that Lean Startup thing, even when it’s just software.  An entrepreneurial software product that works poorly can take down the brand, if, of course, your brand stands for robust, predictable, value and safety.  And if the entrepreneurial product relies on new hardware, be doubly careful.  If it goes belly-up, it will be slow to go away and will put a lot of pressure on that wonderful brand you took so long to build.

If you’re an established brand, it may be best to buy your entrepreneurial products and services from the startups that took the risk and made it happen.  That way you can buy their successful track record and stand it on the shoulders of your hard-won brand.

Image credit – simpleinsomnia

The toughest part of all things is the people part.

Hold on to being right and all you’ll be is right.  Transcend rightness and get ready for greatness.

Embrace hubris and there’s no room for truth.  Embrace humbleness and everyone can get real.

Judge yourself and others will pile on.  Praise others and they will align with you.

Expect your ideas to carry the day and they won’t. Put your ideas out there lightly and ask for feedback and your ideas will grow legs.

Fight to be right and all you’ll get is a bent nose and bloody knuckles.  Empathize and the world is a different place.

Expect your plan to control things and the universe will have its way with you.  See your plan as a loosely coupled set of assumptions and the universe will still have its way with you.

Argue and you’ll backslide.  Appreciate and you’ll ratchet forward.

See the two bad bricks in the wall and life is hard.  See the other nine hundred and ninety-eight and everything gets lighter.

Hold onto success and all you get is rope burns.  Let go of what worked and the next big thing will find you.

Strive and get tired. Thrive and energize others.

The people part may be the toughest part, but it’s the part that really matters.

Image credit — Arian Zwegers