A few weeks back, we wrote a post that spoke to an adjacent set of efforts being conducted at Jet Cooper. We spoke about "eating your own dog food" in reference to our decision to build a web application using the design processes we've refined through the couple dozen applications we've designed for others to date.

I spoke briefly about this at Lean Coffee TO a few weeks back, and the way we structured this experiment seemed to strike a chord.

In case you threw out your Grade 10 textbook (I did), the Scientific Method reads something like this:

  • Pose a Question
  • Gather Information and Research
  • Construct a Hypothesis (a Statement)
  • Perform the Experiment and Collect Data
  • Analyze Data
  • Draw Conclusions, and finally
  • Publish

 

Rocketr began with a question. The question was this:

Does this idea deserve our time, money, energy, and focus?

When you ask it this way, it forces you to start thinking about the casualties that result from a “Yes” answer. ‘Money’ is finite. ‘Time’ even moreso. And as someone once (or, a thousand times) drilled into my head, ‘Focus’ and ‘Energy’ should never be distributed.

So where does that leave a services company like Jet Cooper when they want to invest in a product? I’ve personally witnessed a good number of service-based companies try their hand at this with varying levels of success. Some have, over time, made the move from 100% services to 100% products (not our objective here), but the vast majority have pursued these projects as just that… projects.

The problem with approaching Rocketr as a project was two-fold,

First, we would be forcing this new operation to work within the parameters and constraints of our current operation. It would be given no room to establish unique competencies, culture, or purpose – those would have already been defined. We would also be subscribing it to the same future (and the same means to achieve it) that we’ve set for Jet Cooper.

Second, it could only result in bad decision-making in the long run. What happens when a client project comes along that conflicts with a release date? What happens if Rocketr needs another $10K because we think that’s what will bring the paying customer around? How do you compare a Cost Per Acquisition against a Capacity Utilization Rate?

Are we serious about this?

Rocketr was a product, not a project. If it was going to succeed by its own merits, we had to get serious.

What we decided to do…

We incorporated a new entity that is being incubated inside of Jet Cooper. The new company has a Product Lead, a Technical Lead, and a Design Partner – Jet Cooper – as owners. It has a separate Board of Advisors as well. The Technical Lead (who I wrote about previously), the Product Lead (myself), and Jet Cooper, have each invested funds towards the creation of a runway – 3 months to be exact (although with the application of some Lean Principles, those funds will probably carry us a lot further).

The objective for these 90 days is to discover the Rocketr business model and show evidence of it through paying customers. Ambitious, but doable.

We are going to break the 90 days down further into 3 sets of 30 days. At the end of the first 30 days, we will release a prototype to a group of users ranging in web and technology savvy. We’ll conduct 3 solid days of usability tests with them.

At the end of 60 days, we will re-release the application to the same group of people (having made our course-corrections from the previous round of feedback), as well as a new group of users who weren’t exposed to the first prototype. By the 90th day we intend to ship. Rocketr will go to market in 3 months.

We didn’t necessarily intend for it to be this scientific, but looking back on our early decisions, it seems to line up relatively well;

  • Question: Are we serious about building a product?
  • Research: The failed attempts at launching products as projects.
  • Hypothesis: We can build a sustainable entity with Lean Principles.
  • Experiment: 3 Sets of 30 Days, 2 Sets of User Tests, Ship on Day 90.

As for the rest of the steps – time will tell. We’re openly documenting this experiment and the next few posts will reveal what Rocketr is supposed to achieve, how we’ve tweaked our processes to support rapid iteration, and the obvious struggles that come from team formation, defining a Minimum Viable Product, and working within imposed constraints.

No doubt many of you will point out that our plan only looks so far down the road. You’d be right. At Jet Cooper we practice a way of thinking that promotes having a 10 year vision and a 3 month plan. We brought that way of thinking to Rocketr and we’re making the bet that it holds true again. This doesn’t mean that we’re ignoring the impact of our decisions. We have invested in the right legal, corporate structuring and financial setup that can carry Rocketr well into the future, but for now, we are thinking exclusively about a single point in the future…

… the 90th day.

  • http://www.jasonhanley.com Jason Hanley

    I love the idea of creating a separate corporation with its own advisors to manage the new product. That’s brilliant.

    But… (there’s always a but :) The 90-day experiment seems like too short of a time to gauge whether you really have something or not.

    I’m looking forward to seeing the results!

  • http://www.jonlim.ca Jon Lim

    I think we’re all looking forward to that 90th day. ;)

  • http://www.businessbecomesart.com Vinny Verma

    I think this is the best post on this blog so far and it’s getting me really excited about future content.

    Please continue to break down thoughts and processes in this way, I love it.

    Sincerely,
    Vinny

  • http://www.dayfortwo.com Maurice Chang

    cosign Vinny’s comment ^

  • http://twitter.com/drupeek/ Andrew

    Duly noted…. will see if we can maintain a good level of consistency.

    Thanks for the feedback!

  • Michael Chartrand

    I’m very interested in this approach. After working in many businesses that fall into a waterfall structure for product builds, I can see the advantages of working differently to that.

    Point to consider: You’re working without outside constraints to push you, so in many ways, outside of the way normal restrictions that plague most application development teams (pin-point date specific). I would be even more interested to know how this kind of methodology could be applied in a typically hostile project environment (meaning one or more of the core pillars for success in a project are being constrained).

    I do wish you all the best and hope I can be a fly on the wall for an hour or two to see how it’s working out.

  • http://twitter.com/drupeek/ Andrew

    @Michael – I’d argue that we have a very real outside constraint that is *funding*. We need to demonstrate a paying customer (or 2, or 20) by the 90th day, or at most, within the first 120 days. Otherwise, we’re all out money (some of us as individuals and also as a sunk cost for Jet Cooper).

    Granted, it’s not quite this binary. That being said, it does force us to work/think in a very constrained manner.

    Happy to have you check out the app in a usability test as well. :)

  • Michael Chartrand

    Good conversation today @ LeanCoffeeTO. Looking forward to the invite to peer over your shoulder on this one. :)

  • Pingback: Finding the “Minimum” in MVP | Jet Cooper

  • Pingback: Pitch Sooner, Pivot Faster | Jet Cooper

  • Pingback: How To Build A Product In 99 Days | Jet Cooper