Well, I think we've got a pretty good sense now
of what a high-level product specification is.
It's a visual description of your product, it's a brochure.
But let's delve specifically into how you develop one.
Well, the first thing is, there's two constituencies
that we're looking at when we're building a high-level product
specification.
The first one that we haven't even talked about is internal,
and then the second one is external.
First, on internal, if you and I,
and we have another founder-- let's say Anna's developing
a new business-- and we're all thinking
about what the product is.
You're thinking apple, I'm thinking orange,
she's thinking banana.
A high-level product specification
gets us all to the same point.
We had one, they were doing airborne wind turbines.
They all thought that they knew exactly what it was.
It wasn't until we forced them to actually make
a diagram of exactly what it was,
saying how far off the ground it was, that everyone on the team
got on the same page.
And, oh, by the way, so did Todd and I--
who were the instructors for the class-- finally really
understood what it was.
A number of tools in your methodology are like that.
They have both internal and external relevance.
On the one hand, they are aligned to startup
with the customer.
But at same time, they align team members,
within your startup, together.
Right.
And the persona's a great example as well,
where the persona got everybody internally aligned
with who the customer was.
Because, before we go out and talk to the customer,
we have to be aligned ourselves.
And then know who that customer is, and then we go out
and we align externally.
So that's the internal part, Bill.
Let's turn to the external part.
Now we're going to go iterate with the customer.
We've got our house in order, now
let's go iterate with the customer.
We think this is something that could benefit them.
The simplest way to do that is simply to build a brochure.
And build a brochure that says generally what it is.
Don't get into the technological details of it.
Get into what it is, and what benefits it will bring.
If the customer is not buying the technologies,
the customer is buying a solution to his or her problem.
Right.
And I think that's very important on two levels.
Because, first of all, you're not
ready to tell people about your technology,
because you want to figure out what it can be used for.
So you don't want to disclose any technological secrets
anyway.
And you might not know whether you're going to use those.
But secondly, the customer doesn't buy technology,
they buy benefits.
And at the end of the day, the best technology
does not always win.
It's the company, and you can see that time and time again.
The classic one, VHS over beta-- it's
a question of what to the customers value, what benefits
to bring to them; not how great the technology is.
Come on, Bill.
We're at MIT.
People love talking about technology
here all the time, you and your students as well.
That used to happen to us at trade shows all the time.
They come up to us, this is fabulous!
What type of technology are you using in this?
And I'd say, really good technology, who are you.
And I'd want to know who they are,
because if they're just asking about technology,
they very well could be competitors,
they're probably not decision makers.
If they're not interested in benefits,
I'm not going to sit here and explain to them the technology.
I'm going to focus on benefits.
Hold on.
You said something interesting.
If they're interested in the technology, first and foremost,
they are likely not decision makers.
Well, we're going to get to that later in the steps
as to what's the decision making unit.
But we have to remember, the end user
is the one who's going to create the value.
And they are using the product, they're
not building the product.
So someone who uses the product is interested in benefits.
Someone who wants to build the product, almost by definition,
is not a user.
To get a little more concrete, if your potential product is
software, what kind of specification
can you develop for it?
So, a lot of people talk about, let's just go and code it.
What I prefer to do is build wireframes,
show me what the screens look like.
There are products like Balsamiq,
or you could even just use PowerPoint.
We've used PowerPoint to show what it's like.
But to put functionality in the boxes to show,
and then the workflow of how the software would go.
But don't put too much detail, because again, you
start getting connected to it.
And there's special tools out there to help you
with this wire framing-- such as Balsamiq, and other ones--
but that's what we suggest for software.
It's a little harder with software,
but it's all the more important.
And you have to get not just what the screen looks like,
but the different flows.
What about hardware?
Hardware is easier, because you can visualize what it is.
And then you can show people what
it is with diagrams that look quite realistic.
You don't what them to look too realistic,
but it's very easy to change something.
Because it's just a bucket of bits,
or a bunch of electrons on the screen,
so people tend not to get as emotionally attached to that
as they do if they built it themselves.
They also tend, for some strange reason,
not to get as emotionally attached
to a visual representation as if they develop the software.
Yeah, there's a lot of interesting psychology at play
here.
Now, a lot of our students also wanted to develop services.
We've seen that in Entrepreneurship 101.
What kind of specification can one develop for a service?
So, a service is basically a repeatable offering.
And so, in some sense, the repeatable offering
falls into the same category.
You have to describe what it is in a brochure,
it's just not a physical piece.
It's not a piece of software.
But you have to describe what this service is that you're
going to repeat over and over again.
If you're going to do custom work, what we're talking about
doesn't really apply as much.
That's much more a custom business.
And what we're talking about in this online class
is a scalable business.
And that's different.
So, if it's a service, we want a replicable service
that can be sold many different times,
to many different people, and it looks the same.
Can you define for us what is a scalable business,
and a not-scalable business?
Well, going back to what we were talking about in markets,
a scalable business is a similar product
that can be sold to multiple customers.
That's a necessary but not sufficient condition.
It has to be a similar sales process,
and then it has to be word of mouth.
So you need all three of those.
Now I could have great word of mouth in a custom business.
But that, to me, is not a scalable business.
A scalable business means I can see my product sales go up
like this, and hence my revenue go up
by just increasing my production capability.
I don't need to add tons of new people.
I get more and more productive the more I ship.
A lot of our students would have apprehension
about going to a prospective customer with just a brochure.
They'll be afraid that they'll get laughed out
of the room for that,
with the customer saying, is this all you got?
Well, they're right.
I mean, they should be nervous.
The customers is the final arbiter of success for them.
It's like an elite athlete stepping onto the court.
You're nervous before a big game, and they should be.
But you feel better about it if you've
done your work beforehand.
And we have through the previous steps.
Through our primary market research,
we have understood the customer rationally, emotionally,
socially, we understand what keeps him awake at night.
And so, for the first time, with our high-level product
brochure-- which we will iterate on--
we're presenting them with a painkiller for the biggest pain
that they have.
This will excite our customers.
It's not just a vitamin pill that might work or not.
But this is what will give you the confidence
you need to be successful.