Shipulski On Design

Archive for the ‘How To’ Category

To help your team members communicate more effectively, teach them to put their argument on one page.  Teach them what to leave off the page and explain why those things should be omitted. Teach them what’s at the top of the page and explain why.  Help them identify the central element and show them how to make it fill the center of the page.

Teach them that the professionals distill.

They will have difficulty stripping away the clutter.  They will have difficulty shedding the details. They will have difficulty raising the level of abstraction.  Their fear is typically that people (the leadership team) will think they don’t know what they’re doing because their one-pager doesn’t contain all the details.  It’s your job to help them think otherwise.  You have to help them understand that capable people know how to distill their argument to its essence and answer questions about the details when asked.

To help your team members get the tone right, teach them about snarl words and no purr words.  Snarling and purring create a manipulative tone that devalues the argument.  Teach them to use the fewest, clearest, non-judgmental words.  And no blaming words.  Explain that “they” and “them” signal that there are competing factions that aren’t working well together.

Teach them that words matter.

To help your team communicate a complicated process, system, or approach, teach them to create a hand sketch that represents the complicated idea.  The hand sketch method is like the verbal decluttering described above, but teaching them to create a hand sketch takes the distillation to the next level. The hand sketch is not the process itself; it represents the process.  The sketch doesn’t describe the system in full; it focuses on the main pillars. And it doesn’t describe the approach in a flow chart way; it elevates the novel elements.  And to further raise the bar, limit the number of words to an unreasonable number like six or twelve.

Teach them that a sketch demonstrates understanding.

This one-page approach can also be used for problems, planning, and prioritization, but that’s for another time.

Image credit — Tambaco The Jaguar

There is no such thing as losing time.  Time doesn’t reverse itself, at least outside the theoretical physics textbooks. We can spend time on things that will never go anywhere, but that’s wasted time, not lost time. The trick with this type of project is to learn that there’s a fundamental constraint BEFORE running the full project.  Here’s a rule:

If there is a fundamental constraint that blocks the project, work on a different project.

We can work on projects that generate zero customer value, but, again, that’s wasted time, not lost time. The trick with projects that deliver zero customer value is to verify there IS customer value BEFORE running the full project.  Here’s a rule:

If the project will not deliver customer value, work on a different project.

But, to be clear, it is insufficient to demonstrate that the project might deliver customer value.  You must demonstrate that the project delivered customer value.  You should now ask me, “Mike, how can we demonstrate the project delivered (past tense) customer value before we run the project in full?”  The answer is to demonstrate traction.  Traction is objective evidence that the customer spent time and energy in ways that are surrogates for “buying” the offering.

If you create a one-page sales tool, show it to a customer, and they want to buy five, that’s traction.  If, after you show them the one-pager and ask for a $200 deposit, and they give it to you, that’s traction. If you make a non-functional prototype, show it to a customer and describe how it helps them make progress, and they want to buy the prototype, that’s traction.

While, as I said, there is no such thing as losing time, there is another way to think about things that is, I think, closer to losing time.  When you use all your resources to do project A, you lose the opportunity to spend your time on project B. When you do a project that will never launch, you lose the opportunity to spend your time on a project that will.  And when you do a project that delivers zero customer value, you lose the opportunity to spend your time on a project that delivers massive customer value.  This perspective, I think, is preferred because it forces a value comparison among all candidate projects instead of simply evaluating the value of a single project.

And timing matters.  There is a viable time window for each project.  You can be too early and smash your head on a viability window that has not yet opened, or you can start a project too late, and the viability window slams shut on your fingers before you can launch.  And in that way, you can lose out on a project’s viable time window.  This isn’t losing time in the strict sense, but I think talking through time windows is helpful.

Before running a full project, learn that there’s no fundamental constraint.

Before allocating significant project resources, demonstrate enormous customer value.

Before starting a project, assess the relative value of all the viable projects. Think opportunity cost.

Before going all in on a project, make sure the timing is right.  Think viable time window.

Image credit — Tsutomu Taksu

Things move at the speed of trust.  And when they don’t move, it’s because there’s no trust.

Talking about trust won’t make a difference.  Making trust makes the difference.

In fact, if you have to talk about trust, you probably don’t have it.

Building trust must happen before it’s needed.  And since you don’t know when you’ll need it, you might as well start building it today.

Sometimes it takes a lot of trust to tell someone what you know they don’t want to hear.

Ignoring people’s negative behavior can indicate that you don’t trust them enough to call them out.

Giving trust is a good way to accelerate its receipt.

Don’t tell people to trust you.  Tell them to watch you.

Trust is behavior-based.

Trust doesn’t require consensus, but it does require truth.

Relying on trust is risky, but it’s not lonely.

Image credit — Tom Lee

Sometimes it’s difficult to believe in yourself.  Here is a three-step process to elevate your self-belief.

1. Find someone who believes in you.
2. Ask them why they believe in you.
3. Whatever they say, believe them.

What they tell you will be different than what you think of yourself.  They see you differently than you see yourself, and they have an eyeball-based justification for believing in you.  And you are not qualified to dismiss their justification. Their justification is grounded in your behavior. They watched what you did.  They watched you persevere through trying times. They watched you treat people with kindness and respect.  They watched you call out unacceptable behavior.  They watched you say the unpalatable when everyone else was thinking it but was afraid to say.

It may be difficult for you to believe them, but you must.  Their truth, their belief in you, is grounded in your behavior.  They believe in you because they watched you.  They have real examples.  They have personal experience.  Believe them.

And if you still don’t believe in yourself, repeat the process until you do.

Image credit — Wayne S. Grazio

Take a position.  People will have to reconcile their thinking with yours and, together, the crew will deepen the collective understanding.

Take an opposite position.  Announce you are running a thought experiment and take a position that is opposite of the prevailing theory.  Make it good.  Make it deep.  Do it for real.  The prevailing theory will be strengthened, adapted, or discarded, and everything will be better for it.

Take an opposite position to your own prevailing wisdom.  If there’s no one to play with, repeat the previous exercise with yourself.  Give yourself the business.  I bet you’ll teach yourself something and you’ll have better clarity on what you know and what you don’t.

Challenge someone’s best thinking.  Announce you want to help them sharpen their thinking.  Ask them why they think as they do.  When they answer, ask them “why?” again.  Repeat this process until you’ve asked “why?” five times.  This process is aptly named The Five Whys.  If they don’t feel uncomfortable, you’re doing it wrong.

Draw a picture. Announce that you want to help solve the problem. Ask “What’s the problem?”  Then, draw a picture of the problem and show it to the crew.  It won’t be right, but that’s okay.  Ask them to fix the drawing so it captures the problem.  Repeat the process until the picture looks like the problem.  From there, the solving will come easily.  Here’s an old blog post from 2013 with a simple “problem defining” template — How Engineers Create New Markets  and another from 2017 that describes how to sketch a problem — See Differently To Solve Differently.

Make a Map. Check out these two blog posts — To Make Progress, Make a Map (2023) and The Half-Life of Our Maps (2014).

I think it’s better to be clear than correct.  Clarity brings contrast; contrast creates conversation; and conversation begets understanding.

Clarity is king.

Image credit – Natashi Jay

When the cost of the experiment is small, the downside of its potential failure is also small.

Small improvements cost little and can be implemented quickly.

Small improvements make a difference.

If the transformational improvement never sees the light of day because it costs too much to implement, its realized value is less than the smallest improvement that was implemented.

When a small experiment does not go as planned, the learning can be significant (and fast).

Small experiments are funded by small investments that don’t require approval.  Don’t seek approval. Run the experiment.

The second small improvement stands on the shoulders of the first one

If the improvement is never implemented, it’s not an improvement.

Small improvements can be tested under the radar.  When they work well, give the credit to someone who deserves it. When they go poorly, try something else.

Like ants, small improvements gang up to make a real difference.

Once a small improvement is implemented, it stays implemented.  Like a one-way ratchet, there’s no backsliding.

Small improvements add up over time, but only if you bring them to life.

When it comes to improvements, small is beautiful.

Image credit — Jim Roberts – Papa I’m only a little sparrow

To do new things, you’ve got to stop old things.

If you don’t stop old things, you can’t start new things.

Resources limit the work that can be done.

If you have more work than resources, you won’t be able to complete everything.

Spread your resources across fewer projects, and you’ll accomplish more.

If you run more projects, you’ll get fewer done.  Resource density matters.

For new behavior to start, old behavior must stop.

If you don’t stop old behavior, you can’t start new behavior.

When your standard work no longer works, it becomes non-standard work.

When it’s time for new work, non-standard work becomes standard work.

To get more done, improve efficiency.

To get the right work done, improve effectiveness.

New behavior requires a forcing function.

No forcing function, no change.

Things change at the speed of trust.

No trust, no change.

Transformational change isn’t a thing.

Evolutionary change is a thing.

Starting new projects is easy.

Finishing new projects requires stopping/finishing old ones, which is difficult.

Creating a start-doing list is common.

Creating a stop-doing list is unheard of.

Image credit — Demetri Dourambeis

The CEO doesn’t decide if it’s good enough.  The VP of Marketing doesn’t decide if it’s good enough.  The VP of Engineering doesn’t decide if it’s good enough. The customer decides if it’s good enough.

If the product isn’t selling, the price may be okay, but the performance may not be good. In this case, it’s time to add some sizzle.  And who decides if the sizzle is sufficient?  You guessed it – the customer.  And if you add the sizzle and they buy more, the sizzle was the problem.  If they don’t buy more, it wasn’t the sizzle.

If the product isn’t selling, the performance may be okay, but the price may be too high.  In this case, it’s time to pull some cost out of the product and reduce the price.  Maybe a better way is to test a lower price with customers.  If they buy more, it’s worth doing the work to pull out the cost.  If they don’t buy at the lower price, the price isn’t the problem.  You still have some work to do.

If the product isn’t selling, both the performance and the price may be the problem.  It’s time to add some sizzle and lower the price.  But there’s no need to do the work until you test the hypothesis.  Make a one-page sales tool with the new sizzle and price.  If they like it, make it so.  If they don’t like it, make another sales tool with some different sizzle and a different price.  Repeat the process until the customer likes the new offering.  Then, make it so.

If the product isn’t selling, it’s possible the sales channel isn’t making enough money when they sell your product.  To test this, go on several sales calls with them.  If they are unwilling to bring you on the sales calls, it’s a good sign that there’s not enough money in it for them.  There are three ways to move forward.  Reduce the price to the channel partner.  If they sell more, you’re off to the races if, of course, there is enough margin in the product to support the reduced price.  Make it easier for them to sell your product so they spend less time and effort and make more profit.  Sell through a different channel.

When your product isn’t selling, figure out why it isn’t selling.  And because there are many possible reasons your product isn’t selling, it’s best to create a hypothesis and test it.  Your job is not to solve the problem; rather, your job is to figure out what the problem is and to decide whether it’s worth solving.

If you create a one-page sales tool with a lower price and customers still don’t want to buy it, don’t bother to design out the cost or reduce the price.  If you create a one-page sales tool with a new DVP and the customers still don’t want to buy it, don’t do the work to develop that new DVP.  If you test a reduced price to the channel and they sell a few more systems, don’t reduce the price because it’s not worth it.

Once you have objective evidence that you know what the problem is and it’s worth solving, do the work to solve it and implement the solution.  If you don’t have objective evidence that you know what the problem is, it’s not yet time to solve it.

There’s nothing worse than solving the wrong problem.  And the customer decides if the problem is worth solving.

Image credit — Geoff Henson

You know you know, but you don’t.

You think you know, but you don’t.

You’re pretty sure you don’t know.

You know you don’t know, you think it’s not a problem that you don’t, but it is a problem.

You know you don’t know, you think it’s a problem that you don’t, but it isn’t a problem.

You don’t know, you don’t know that you don’t need to know yet, and you try.

You don’t know, you know you don’t need to know yet, and you wait.

You don’t know, you can’t know, you don’t know you can’t, and you try.

You don’t know, you can’t know, you know you can’t, and you wait.

Some skills you may want to develop….

To know when you know and when you don’t, ask yourself if you know and listen to the response.

To know if it’s a problem that you don’t know or if it isn’t, ask yourself, “Is it a problem that I don’t know?”  If it isn’t, let it go.  If it is, get after it.

To know if it’s not time to know or if it is, ask yourself, “Do I have to know this right now?” If it’s not time, wait.  If it is time, let the learning begin.  Trying to know before you need to is a big waste of time.

To know if you can’t know or if you can, ask yourself, “Can I know this?” and listen for the answer. Trying to learn when you can’t is the biggest waste of time.

Image credit — Dennis Skley

Growing a company is challenging.  Here are some common difficulties and associated approaches to improve effectiveness.

No – The way we work is artisanal.

Yes – We know how to do the work innately.

It’s perfectly fine if the knowledge lives in the people.

Would you rather the knowledge resides in the people, or not know at all?

You know how to do the work.  Celebrate that.

No – We don’t know how to scale.

Yes – We know how to do the work, and that’s the most difficult part.

It doesn’t make sense to scale before you’ve done it for the first time.

Socks then shoes, not shoes then socks.

If you can’t do it once, you can’t scale it.  That’s a rule.

Give yourselves a break.  You can learn how to scale it up.

No – We don’t know how to create the right organizational structure.

Yes – We get the work done, despite our informal structure.

Your team grew up together, and they know how to work together.

Imagine how good you’ll be with a little organizational structure!

There is no “right” organizational structure.  Add what you need where you need it.

Don’t be so hard on yourselves.  Remember, you’re getting the work done.

No – We don’t have formal production lines.

Yes – Our volumes are such that it’s best to keep the machines in functional clusters.

It’s not time for you to have production lines.  You’re doing it right.

When production volume increases, it will be time for production lines.

Go get the business so you can justify the production lines.

No – We have too many projects.  It was easier when we had a couple of small projects.

Yes – We have a ton of projects that could take off!

Celebrate the upside.  This is what growth feels like.

When the projects hit big, you’ll have the cash for the people and resources you need.

Would you rather the projects take off or fall flat?

Be afraid, celebrate the upside, and go get the projects.

No – We need everything.

Yes – Our people, processes, and systems are young AND we’re getting it done!

Assess the work, define what you need, take the right first bite, and see how it goes.

Reassess the work, define the next right bite, put it in place, and see how it goes.

Repeat.

This is The Way.

Attitude matters.  Language matters.  Approach matters. People matter.

Image credit — Eric Huybrechts (Temple of Janus)

When I want to understand a large system, I make a map.  If the system is an ecosystem, I combine Wardley Maps by Simon Wardley with Wide Lens / Winning The Right Game by Ron Adner.  On Wardley maps, activities and actors are placed on the map, and related elements are connected. On the left are infant and underdeveloped elements, and on the right are fully developed / commodity elements.  It’s like an S-curve that’s been squished flat.

Wide Lens prompts you to consider co-innovation (who needs to innovate for you to be successful) and adoption (who needs to believe your idea is a good one).  Winning The Right Game makes you think through the sequence of attracting partners like a visual time-lapse of the ecosystem’s evolution.  This is a killer combination that demands you put the whole system on one page – all the players/partners, all the activities sorted by maturity, all the interactions, and the evolution of the partner network and maturity of the system elements.  This forces a common understanding of the ecosystem.  There’s no way out.  Did I say it must fit on one page?

When the large system is a technological system, I make a map.  I use the best TRIZ book (Innovation On Demand) by Victor Fey.  A functional analysis is performed on the system using noun-verb pairs that are strung together to represent how the system behaves.  If you want to drive people crazy, this is the process for you.  It requires precise words for each noun (element) and verb (action) pair, and the pairs must hang together in a way that represents the physical system.  There can be only one description of the system, and the fun and games don’t stop until the team converges on a single representation of the system. It’s all good fun until someone loses an eye.

When I want to understand a business/technology/product/service offering that has not been done before (think startup), I use Lean Canvas by Ash Maurya.  The Lean Canvas requires you to think through all elements of the system and forces you to put it on one page. (Do you see a theme here?) Value proposition, existing alternatives, channel to market, customer segments, metrics, revenue, costs, problems, and solutions – all of them on one page.

And then to blow people’s minds, I combine Wardley Maps, Wide Lens, Winning The Right Game, functional analysis of TRIZ, value in action, and Lean Canvas on one page.  And this is what it looks like.

Ash’s Lean Canvas is the backplane.  Ron’s Wide Lens supports 6 (Channel), forcing a broader look than a traditional channel view. Ron’s Winning The Right Game and Simon’s Wardley Map are smashed together to support 2 (Existing Alternatives/Problems).  A map is created for the existing system with system elements (infants on the left, retirees on the right) and partners/players, which are signified by color (red blob).  Then, a second map is created to define the improvements to be made (red circles with arrows toward a more mature state).  Victor’s Functional Analysis/System diagram defines the problematic system, and TRIZ tools, e.g., Separation Principles, are used to solve the problem.

When I want to understand a system (ecosystem or technological system), I make a map.  And when I want to make a good map, I put it on one page.  And when I want to create a new technological system that’s nested in a new business model that’s nested in a new ecosystem, I force myself to put the whole universe on one page.

Image credit – Giuseppe Zeta