Unoriginal

Time to take a look at one of the other components of the whole VC/startup/biztech world - the Entrepreneurial Book. These are the books you see in the airport promising to teach you how to be a better leader, manager, inventor, or whatever you believe you are in 10 easy to digest feelgood chapters. I've read a few myself and usually they're like a sugary treat - makes you feel good when you read it, but no long lasting benefit, and might actually rot your teeth a little.

Recently Adam Grant published "Originals" about "How non-conformists move the world" and online put up part of one of the chapters to be read as a sampler - in this case it's the chapter about Meredith Perry and uBeam. I read it expecting to read at least part of a story I was familiar with.

As it happens, the bits I was around for, and I was around for a lot of them, I will politely describe them as "not at all how I recall them". Let's start with the biggie.

She (Perry) did something that flew in the face of every piece of wisdom she had heard about influence. She simply stopped telling experts what it was she was trying to create. Instead of explaining her plan to generate wireless power, she merely provided the specifications of the technology she wanted. Her old message had been: “I’m trying to build a transducer to send power over the air.” Her new pitch disguised the purpose: “I’m looking for someone to design a transducer with these parameters. Can you make this part?”

Let's continue with the obvious. About 10 seconds after you get someone contacting you to do work for them, their name or the company name has been Googled and you're reading all about them. In case you hadn't noticed, Meredith Perry gets plenty of publicity for uBeam, and the press coverage made it very, very clear what she was trying to do. So apparently us engineers are super tech savvy but can't Google some articles? No - before I'd even replied to the first contact, I knew exactly what they were doing.

Next is the practical. I'm being spoken to because I'm highly experienced in the field you're needing work in - I've seen a lot of different problems in this space. Once I get the general idea of what you're trying to do, I already know the rough specs of what you are looking for. If you give me specs that are different, I'll try to find out why, whether it's that I'm not understanding your requirements, or you're not understanding the issues. The converse is this - if you give me specs, I have a pretty good idea of what you're trying to do. I've shocked plenty of cold callers when I've worked out what their "super secret" project is from just a couple of questions.

Then there's the engineering side of things. If you give me a spec for something way, way different (let's say less difficult) than what you actually need, I'm going to make choices and compromises in the design to hit that spec, and not the 10x you really want. Like most engineers I pride myself on delivering a good product that meets (and maybe slightly exceeds) your needs in an economical manner - if I overbuild like that, you as a customer will likely be unhappy with the invoice, and reasonably so. Those design choices and compromises mean it's most likely not something that could ever scale to that further 10x. I probably will have to do something different for that, and then tell you that I have to start all over again. Give me something too simple and most times I'll point you to someone that already sells it, because pedestrian stuff is not something I'm interested in. 

I've taught this to people who've worked for me - If the person sitting opposite you is smart, experienced, and knowledgeable then don't bullshit them, they know what it smells like.

So that part from the book is not how it was pitched to me, nor is it how it was pitched to anyone else when I was present, in my recollection.

Then there's this:

It was enough to attract a first round of funding and a talented chief technology officer who had initially been highly skeptical. “Once I showed him all the patents, he said, ‘Oh sh*t, this actually can work.’ ”

Now I wasn't there for this part, however to me this does not sound like the CTO I came to know very well, nor does it resemble any of the 'origin stories' that I heard from him. I have to wonder, did the author confirm this statement with the CTO? Which of the engineers that work(ed) for uBeam did the author interview to confirm their initial skepticism, or that the pitch to them was anything other than what we all see in the press? Not me.

So in summary, and as a rehash of what I've said before - for me joining uBeam was principally because of that CTO, and that the engineering problem was hard. Had it been pitched any other way, I would have passed.

Adam Grant might want uBeam to be the story that's another proof point for his thesis, but in my opinion it doesn't hold water. And now I wonder that if I happened to know as much about all the anecdotes in these books, would I have the same opinion of all of them as I do this?