And in fact this is often a point of confusion,
that the traditional Lean Startup way of looking at this,
you probably heard of the build, measure, learn loop.
And so this is the way that this sort of Lean Startup process is often presented.
And so here it's kind of implied that you should build first,
but in fact most practitioners will tell you,
no you should really start the loop here at the learn step.
So one of the things you'll learn as we go through this in more depth and
then you enhance your own practice of this is,
where are we in this loop for a given assumption or experiment.
So think about that as you go and
you approach your own particular problems with this.
So, I mentioned how we're trying to create a culture of experimentation here, so
we're trying to use this technique not just for really big ideas and really big
questions, but also for tactical things that are nevertheless very important.
And will over time will occupy most of our hours and
investments that we make in the product.
Let's look at a really small example for HVAC in a Hurry.
So what was the product and why were they working on this?
Why did they think it made sense?
Let's talk about this facet of the results page for
when the technicians are searching for a part, they see a set of results.
If you remember, we had this idea that it might be a good idea to
sort the results by the amount of times things were ordered.
So for example, here you saw that this one's ordered 87, 12, 2, so
they're ordered in descending order.
And the idea,
is that the one that's ordered the most is most likely to be the right result.
That was to deliver on these narratives here.
Okay so why did we build this again, and
how will we know if that was really a good idea or not?
Well, we had the assumption that, if we order these things, and
we generally create this feature,
then, the HVAC technicians will use it, and, it will increase their performance.
That was sort of our overall hypothesis and assumption in this very general area.
And then, let's look at how we got to that.
Well, the HVAC in a Hurry team started out, and
they had this very general envelope that they were operating within of let's
build an app, let's invest in software to increase the performance of the business.
And looking around they decided that since it's
really the technicians out in the field that are driving most of the revenue for
the company and their advice from Vince who runs that part of the business,
was that they struggle a lot out there in the field with the support that they get.
They decided to start with the technicians.
And then if you remember they had this idea that, well we should create a way for
them to get parts documentation.
But when they went out and they asked the technicians what's on your A list,
what's hard?
They found out that, that wasn't on their A list at all, that in fact it was really
or one of the most important things was just finding out the pricing and
the availability for a part, while they're out there in the field with a customer.
So that they know what their next step is and they can decide that and
inform the customer.
And so then, they created this assumption that I mentioned a minute ago, that if we
build something where the technicians can look up parts availability and pricing and
then they'll use it and find it useful and it will increase their performance.
And so they created the product proxy,
the concierge MVPs that we talked about earlier, and then they loop through and
we created user stories and prototypes which we just saw to test this.