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 three 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 worldwide, 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 many 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, and 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 to feed my creative addiction. I don’t have the resources of Apple, and the last thing I want to be distracted with is non-additive busy work.
For the integrated product suite to work, the following has to hold:
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 its 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, the 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 pursuing deeper customer/problem understanding. In the last couple of years, I’ve created many quick and dirty MVPs. The ones that were initially stuck got turned into products for further value testing. Those who 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 solo, at some point, you need help to scale.
I wrote two posts describing each of these stages:
1. Achieving Flow in a Lean Startup
2. Scaling Flow in a Lean Startup
Since then, the Spark59 team has grown from 1 to 3.5 core resources plus three 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 a 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. Several entrepreneurs responded.
Even though all of them were busy with their 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 were driven to learn. The results from that 2-week project were so addicting that I continued working with a number of them on a freelance 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 startup — their 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 six 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 new hires 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
For instance,
- 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 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 much more to share about 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…
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!
- Ash
P.S. I also got hit by a bug during the holidays for writing another book.
We’ll see if it lasts.