Bill, it's great to see you again.
It's great to be back on the never ending journey
for perfect entrepreneurship.
The journey continues.
That's why we're here.
And actually I want to pick your brain
about developing a concept for a product.
We've been asked this question a lot.
That's why we're here.
And that's what we're going to deliver at the end of the day
is a product to our customer.
So at some point here, we need to get into what is it?
What is the product?
Do you have a framework for developing
a concept for the product?
So I've evolved over time to this concept of a high level
product specification.
When I hear this term, I hear "high level"
and at the same time I hear "specification."
And that seems to be a contradiction in terms.
Specification mean specific.
High level means lack of specification.
So what we're trying to do is get the best of both here.
We're trying to define for the first time what our product is
so we can start to get a common understanding without getting
bogged down in too much specification.
That will come in time.
So the high level product specification
is a visual representation, focusing on what will it do,
what are the benefits that it will produce,
not the underlying technology inside of the black box.
But what will it do and what will the benefits
be, and be very visual.
Just to clarify specification does not mean prototype?
No, it's very important not to build a prototype
if you can avoid that.
I'm an engineer.
I love to build prototypes.
I work with engineers every day.
And there's a lot of joy in building a prototype,
because you've built something that is yours
and you're proud of.
That's exactly the problem, because once you
build something, you start to get emotionally attached to.
This is what's called the IKEA effect.
Many behavioral economists have studied
this, such as Daniel Ariely at MIT, who's now at Duke.
And they've shown that this chair, which is built at IKEA,
if I built this chair, I would overvalue this chair.
In other words, if the same chair, the same pieces
and parts we're built by a master builder,
and I took the same parts from IKEA and built it,
I would think that this chair is worth more than the other one--
even though the other one is clearly a better chair.
This is the emotional attachment we get to things that we build.
Bill, what I love about your approach
is that you're the first to say that you didn't know most
of the things when you started.
That's fair.
I didn't know anything when I started.
So I do wonder in what context did
you learn the importance of this tool that you advocate,
high level product specification?
Yeah, well, I learned the hard way by making mistakes.
But sometimes it's the best way to not forget it.
When I was at Cambridge Decision Dynamics
and then at SensAble and then at Viisage,
I started to realize over time that how much money you spent
and effort you spent on developing the product
didn't mean that the product was better received
in the marketplace, didn't mean it
was a better product for your customer.
It just meant you spent more money on it.
And you were more committed to that product.
And you tried to push it harder.
So I think it's critical to think about when do you
spend that money on product development.
And I found what was more an indicator of success
early on was how many times did you
iterate with the customer, kind of getting your ideas refined
and refined and refined.
And it was faster and cheaper to do that
by just showing high level product
specification or a brochure sample brochure
that you weren't that committed to.
How can this be so simple just presenting a visual brochure
to the customer?
It isn't always so simple.
Sometimes it is.
I've seen it in my students in class.
Sometimes it is.
And you try to push that way.
But for instance, at SensAble, how
do you explain to someone in a brochure
that you could go into a computer,
grab something, and move it around like this,
and feel what it was like, and to form it and change it?
So in that case, we did do a demonstration system.
But we made very clear to everyone
that this was purely a demonstration system
and all the code would be thrown out,
and we could redo the hardware.
Anything was re-doable.
But we just wanted to make the point
and let people know you actually could feel stuff
in the computer.
And it had high quality resolution.
And it was really quite spectacular for them.
So in a brochure, a picture's worth a thousand words.
But sometimes if something goes beyond just a picture
and you can't do in words, doing a quick demonstration
system with the right caveats around it can be necessary.
If you're creating a completely new product--
and some products are like that, just
like your product at SensAble-- perhaps
brochure might not be enough.
But there are startups that are not only
creating entirely new class of products,
they're offering a new business model innovation.
They're offering an improvement in existing process, where
actually creating a high level brochure
might be a good way to explain to the customer what's at play.
I have never seen a business-- and I've
seen thousands of them, startups--
that couldn't benefit by making a well-crafted brochure.
And then if you might need something else
like I was talking about at SensAble,
you could do that as well.
But to say that it's something entirely new
that a brochure won't do it, I don't find that credible.
I think that's just trying to get out
of building a brochure when you really should build a brochure
and then think what's the minimal amount you can do
otherwise to convey what this profound new functionality is.
Someone who looks at this subject
skeptically might say, well, it's
getting so cheap to make things today.
Wouldn't you save time by coding up a beta site,
by developing a product, and then showing to the customers,
and then iterating very quickly.
Yeah, I hear that a lot as well.
The problem is as soon as you write code--
and I know that because I've written
code-- is you get attached to it.
And it's like asking someone to correct their own homework
after they've done their homework.
It's better to make the high level wire frames of it
before you start coding too much.
Now, if you get to the point where people are buying off
on it, and you can move to doing something,
make sure that the code that you're doing,
everybody understands that's demo code
and could get thrown away.
Don't allow this kind of emotional attachment
to be built into it.