I love this time of the year.
Everyone is upbeat around the holidays. The pace is slower. It gives me time to reflect.
In the 3 short years since I started this blog, a lot has changed in my life. I just got back from a short trip to Japan (too short) for the book launch of the Japanese translation of Running Lean. Other translations into Korean, Mandarin, French, and possibly Spanish, Dutch, and Vietnamese are also in the works.
For me, this has been a rather unexpected (and welcome) ride which started right here on this blog with my first post back in October 2009 titled: “How I learnt to grok Customer Development”.
I started this blog simply because I had more questions than answers. Now I am running workshops around the world, advising and coaching teams, and running a new company with a great team of fellow lean practitioners.
First, thank you all for your continued support along the way…
Here are some of my biggest lessons learned in 2012.
Connecting The Dots
One of the questions I get a lot is: “So what do you do now?”.
Saying I’m an author/speaker/consultant is the easiest answer but I don’t identify with any of those labels. I generally have an aversion to labels. “Practicing entrepreneur” would probably be the closest.
I still love getting my hands dirty building products and I have my hands in a lot of things — bootcamps, workshops, Lean Canvas, USERcycle, Lean Stack.
Some say too many.
My friend, Noah Kagan, has been pushing me to kill off all my projects but one. To which I used to meekly respond: “but they are all somehow connected”. I believe it’s critical to cast a wider net at the outset in search of value for the right problems and customers.
But he did have a point.
Value creation does not scale by itself. At some point, you have to converge to a narrower customer/problem space and shift into systems thinking and optimization. Knowing when to shift from search to optimization is fuzzy.
Noah felt I had enough going to make the shift around a single “product”.
I felt I needed more.
I’ve spent the last year thinking about this deeply. I think there is an “Integrated Product Suite” argument to be made for a multi-product strategy (even for a startup) where the sum of the parts is truly greater than the whole.
The classic example is Apple.
The iPhone, iPad, Macbooks are each solid stand-alone products but the experience is orders of magnitude better when you pair them together.
That said, this isn’t a cop out to pursue multiple products just to feed my creative addiction. I don’t have the resources of Apple and the last thing I want to be is distracted with non-additive busy work.
For the integrated product suite to work, the following has to hold true:
Each product has to fit within a larger customer lifecycle
It goes without saying that each product has to meet certain success metrics to justify it’s existence. But the power of the integrated product suite is only realized when each product also naturally fits into a larger customer lifecycle. Once you understand and baseline this larger funnel, prioritization of products becomes clearer.
Each product is cut from the same business model canvas blueprint
For the integrated product suite to work, each product needs to serve the same overarching customers and set of problems. They need to serve the same business model canvas with lots of overlap and a customer journey story that weaves the products (solutions) together.
The integrated product suite is emergent versus deliberate
It’s hard enough trying to deliberately create one successful product. I believe these secondary products emerge as by-products while in pursuit of deeper customer/problem understanding. In the last couple of years, I’ve created lots of quick and dirty MVPs. The ones that initially stuck, got turned into products for further value testing. Of those, the ones that could be weaved into a customer journey story made it into the product suite. All others were eliminated.
Building a Solid Foundation
Work happens either inside the building or outside the building. Both are required. But you can’t be in two places at once.
While you can start out solo, at some point you need help to scale.
Since then, the Spark59 team has grown from 1 to 3.5 core resources plus 3 additional non-core resources.
Here are some lessons learned from hiring and growing a core team:
Hire for passion for the problem (not just for the solution)
In my last company, I hired specialists to outsource building and non-core activities. In this company, I am hiring learners with passion for the overarching problem. Sounds like common sense but I stumbled into this one accidentally.
While I was experimenting with Lean Canvas back in 2010, I needed help creating an online MVP. I was too busy to hire and direct a freelancer so I put a call for help on my blog. A number of entrepreneurs responded.
Despite the fact that all of them were busy with their own startups, the level of conversation and productivity was unlike anything I had previously experienced. They all had the necessary problem context, were self-directed, and driven to learn. The results from that 2 week project was so addicting that I continued working with a number of them on a freelancer basis and that became my model for growing the team.
Finding the right team takes time
The obvious challenge with this approach is that everyone had their own startup — their own primary project which was their #1 priority.
This approach was like trying to date people already in a committed relationship.
Not everyone made the jump. The typical jump time for those that did was at least 6 months. But I wouldn’t do it any other way. There is no substitute for determining fit than time.
Building a core team requires lots of patience
Even after the jump, setting up the right systems and culture takes lots of daily commitment. My vision is one of creating a learning organization that is modeled more like a martial arts dojo than a typical company. Everyone is a practitioner in-training.
The first challenge for a new hire is shedding off their years of specialization bias and learning to think more empirically.
In the beginner’s mind there are many possibilities, in the expert’s mind there are few.
- Shunryu Suzuki, Zen Mind, Beginner’s Mind
- Developers typically suggest solving problems with more code.
- Designers typically suggest solving problems with better ux.
- Marketers typically suggest solving problems with better copy.
It is natural for us to approach problems with this specialization bias. That is what we are good at. What we’ve been trained to do. But without the right evidence-based focus, despite our best intentions, building alone will often yield waste.
The Overarching Theme
This last year has really been a search for an overarching theme that collapses all my different products into a single product — Spark59.
At the highest level, there is just one customer / one problem, and a set of solutions that work either stand-alone but are more effective when used together.
The vision for Spark59 is best captured by this manifesto I shared in an earlier post.
The overarching theme that unifies the various products is “Innovation Accounting”. This is a term Eric Ries first introduced in his book: “The Lean Startup” and one that I find quite fitting.
Here is my paraphrasing of the term:
Innovation Accounting helps entrepreneurs define, measure, and communicate progress with their internal and external stakeholders.
I’ll have a lot more to share around this topic in the new year.
Here are some highlights:
- How to generate the right hypotheses to test
- How to scale experiments in a team
- How to measure without drowning in a sea of numbers
- How to learn from every experiment — especially those that fail
- and lots more…
To get a jump start on some of these ideas, you can grab a FREE 5-part course I just finished creating.
That’s all I have for now. I look forward to continuing the conversation in the new year.
Here’s to your success in 2013!
P.S. I also got hit by a bug during the holidays for writing another book.
We’ll see if it lasts.