Specifically, I’ve drawn a lot of value from the story of Stone Soup.
For the unfamiliar, it’s a very old story of a tramp who travels to a town in search of some food. Hungry and destitute, he knows better than to ask the townfolk for a handout. Instead, he offers the villagers the best soup they’ve ever had, “Stone Soup.”
Having intrigued the villagers, he drops his “soup stone” in a large pot and brings it a boil. He tastes it, adding that it just needs a bit of barley and salt to be complete. Then, the story goes, he gradually asks other villagers for more ingredients to make it “just right”: chicken stock, celery, flour, and so on. Everyone shares in the soup, and the stone is extracted, ready to earn a free meal for its owner in the next town.
Starting with nothing
Most projects (especially software projects) are astonishingly like this story.
If you’re building software for a customer or group of customers, you must start with only a stone and a promise of soup to come. That’s probably a familiar feeling to many developers.
Unless you’re writing software to an exact set of specs (in which case, you’re doomed, sorry to say), your customers don’t know exactly what they want. They also don’t want to provide you with the tools, data, and requirements you literally can’t move forward without.
Making matters worse, their expectations are that you’ll magically appear with the project, after reading their minds, overcoming all obstacles, and satisfying all dependencies.
Stone soup is how you show them some of this magic.
Some see the tramp in this story as a charlatan, but I am going to use the term “instigator”: the guy or gal with the guts to set up a pot of boiling water and throw in the stone. The instigator goes out on a limb to make things happen.
Here’s how you can start making some soup:
Find your stone
You are now the keeper of the stone. You’re the instigator. Why you? Because you are probably the only person that knows there’s even supposed to be a stone.
In my experience, throwing the stone into the pot involves skipping a lengthy requirements phase and taking that risky first stab at the product.
There are arguments for building low-fi mockups and some for high-fi, functioning prototypes. As I’ve gotten better at building products, I’ve found high-fidelity prototypes to extract more valuable feedback.
I’ve also heard this called a “straw man”. The point is to start the conversation by putting something in a customer’s hands to either love or hate.
Projects often grind to a halt when people fail to deliver on their part of the bargain. This is where I’ve watched projects languish and then die.
Momentum is everything in this phase. No, you won’t get all the ingredients you think you need for your soup. But you do need ingredients of some kind or the boil dies down, interest is lost, and everyone goes home with empty stomachs.
So if one person or group isn’t delivering and is holding things up, it’s time to get creative. What can you put in that would move the conversation forward? Can you get data from a different source that would still be valuable? Can you show a reasonable facsimile of this feature using only the tools you have on hand?
This ingenuity both helps solidify the product and creates a vacuum for the actual item you need, pointing a spotlight on the reason it’s being held up.
The finished product
Actually, that’s kind of a misnomer. The product is never finished.
But after a few iterations on the original concept, you have something worth sharing, even if it’s not perfect. You may never have all the ingredients you’d planned on, but just getting the wheels unstuck generated an outcome that would never have existed otherwise.
At a micro level, the instigator never knew how the soup was going to turn out. The ingredients and tools on hand vary wildly. But at a macro level, he or she knew enough about the process to guide the participants to a shared goal: making something great.
Want to change the world? Be an instigator.
To be successful as an instigator, you must have a decent mental picture of how the soup gets made. If it’s a software project, you’d better have a working knowledge of the parts of the process, from servers, to data, to code.
Once armed with this knowledge, developing a habit of making stone soup is what sets leaders apart from those who are led. It gives you the ability to know that you’ll be able to deliver a result, even without a sure knowledge of exactly how you’ll do it.
Most people aren’t wired to want to be instigators. It’s scary and the risk of failure or embarrassment seems high. But it’s a skill that can be learned, and whether you’re a coder, a manager, or an entrepreneur, it’s required if you want to help lead successful projects and create great products.