The Tech Entrepreneurship Blog

where technology and entrepreneurship meet

Tag Archives: Technology

Three Core Tech Trends

Leave a Comment Posted by on August 2, 2012

There are, in my mind, three major technology trends in this decade’s consumer electronics world: narcissism, visual realism, and naturalism in interaction.

1) Narcissism

Narcissism is less interesting to TandemLaunch, but has become a major driver of our economy.  We all want to be famous, we all want to be the greatest person on earth, and it is in many ways a biological and psychologically ingrained desire.  For the first time in human history, the internet has made that possible to the masses, or at least in the somewhat narrow view of ‘fame’ which society has defined.  Guys like Mark Zuckerberg understand this, and realize that if you provide people with perceived fame, they will freely give up all kinds of higher order desires like ‘privacy’.  It is clear that narcissism drives a major part of the economy, including social network systems, photo sharing, and anything where you can share some part of your life.  These are basically all technologies that allow you to have hundreds or even thousands of friends, be liked by tens of thousands, contribute to revolutions in far off countries, and, to put it frankly, become famous without the actual effort of having to leave your couch.  How much better can it get???

2) Realism

We are entering a world where there is a strong push in consumer electronics not just for functionality, as is the case with computing power, but actual visual, auditory, and otherwise sensory realism.  We have displays that are approaching the human eye’s perceptual limits (Apple’s Retina display for example) and we have audio systems that are approaching the limits of the human auditory system.  This is all a push towards creating technology that looks, feels, and sounds no different than the real world, and there are still opportunities left in this field worthy of technical development.

3) Natural Interaction

Naturalness of interaction for computing devices (touch or gesture recognition), as well as interaction with other human beings, is becoming more and more necessary as many of our human to human interactions are currently done through some sort of computing device.  The emergence of video conferencing, online gaming, and technologies of the like are really about a chain of interactions: interactions between a human being and a computer, that computer and another computer, and interactions between the end computer and another human being.   The goal is to make that chain as natural as a face to face interaction between one human being and another.  This is where I believe there is a lot of opportunity.  In fact, the last trend is possibly the biggest because it is by far the least tapped into.  If you do the same analysis that I just did for realism (take the set of things that human beings would like to have and subtract our current capabilities), you’re left with a laundry list of technical challenges.  This is precisely why TandemLaunch’s first investment was in Mirametrix’s eye gaze technology: an affordable, non-contact, gaze tracking solution that integrates with gesture and speech recognition for your living-room environment.

Technology Transfer , ,

Tales of a Product Manager’s Television debut with M.Net!

Leave a Comment Posted by on July 12, 2012

So Mirametrix was invited to the M. Net show on the 18th of April 2012 to present our Mirametrix S2 Eye tracker. Being the product manager, that meant I was the person to show off our product.  Fantastic! Right?

But this is a live taping (Welcome to the world of live TV demos. no second takes if something goes wrong), it’s my first time on live television, I have no clue what questions I will be asked (the bane of the over-prepared), and  it’s the first time our product will be used on a TV set… by a co-host who has never tried an eye tracker before.

Fortunately, I was confident about our product performing well, and had done this presentation enough times to be able to recite my monologue and think about what to make for supper at the same time(I am the product manager after all). Still, many questions were on my mind, such as ‘What should I wear?’ and ’Should my hair be straight or curly?’

The day of the taping, the usual nerves kicked in: ‘Oh gosh, what equipment should we bring? Do we have the laptop ready with the demo? Do we have a backup, extra screens and cables?’ I asked one of the interns to help me get everything ready, test the demo multiple times, and over pack.

We arrived at the studio while another live show was taping, with half an hour to set everything up and test the demo.  I got a quick tour of where I would be sitting, and where the demo will take place. With the help of our intern, I started setting up and testing.  After a few necessary ‘everything that can go wrong, will go wrong’ modifications, we got the demo up and running. Just when I start relaxing, I am told that we can’t have the equipment installed before the show, because it will take up too much space on the table for the first segment. I panic. “You mean I’ll have 30 seconds during the commercial break to set up everything and test again?” Yes.

We unpack everything and hide the pelican case in a corner.

I go upstairs where I meet the host, Denis Talbot and the other people on the team.  He was very nice and made me extremely comfortable, until he announces that he will not be going over the questions with me now to make sure the conversation flows naturally. With the demo not set up, and no way to prepare myself for the questions, it felt like they had stabbed my over-prepared self in the heart and were asking me to wing it!

The show is about to start, we are taken downstairs and I am sitting in the background while other segments are presented. I get quite comfortable thanks to the intern that came with me and Claude Arson, the researcher for the show.

It’s the commercial break, we get all the demo setup in 30 seconds and Tristan Geoffroy, the co-host and guinea pig for the eye tracker, tests it quickly, they place the microphone on me and… WE ARE LIVE!

Want to know how I did? You can watch my segment at 15:30.

So, what did I learn from this nerve racking/stressful experience?

1) No tech talk:  Product managers tend to get lost in technical details when trying to explain their technology. The general population will not remember HOW it works, but WHAT it does. Focus on applications and key features and avoid the technical lingo.

2) Keep it simple: Yes, there might be 324 applications of your technology, but the capacity of human short-term memory is in the order of 4 to 5 items max. Think about what these 4 items should be and make sure they are explained in a simple way for people to understand and remember them.

3) Don’t worry, I’m a professional:  Trust the TV crew. They are good at improvising if anything goes wrong and at helping you showcase your technology in a great way. Between camera angle changes and pre-recorded videos, they keep it dynamic and interesting and can hide minor glitches.

Thank you to Julien Limoges, our intern, for being my moral support during that day and staying with me during the taping!

Demo Stories , , ,

The CTO Role Broken Down

Leave a Comment Posted by on May 22, 2012

The CTO fills a critical role in a technology startup. The title is really broad, and people tend to cling to different aspects of it, but what do you really need your CTO to do in a startup? Here’s a quick breakdown for aspiring Chief Technology (or Technical) Officers.

 ‘Chief’ communicates hierarchy and seniority. A chief, by definition, is a management role. There is a big misconception about who should be a CTO. A CTO shouldn’t necessarily be the smartest code developer because, as a CTO, they must by definition be an integrator and a manager of people. CTO’s have to understand the entire organization.  Specifically, they need to understand what all of the technical parts of the team are up to, what all the players in the organization are up to, and what the programs are that are underway. Moreover, this must be done in a way that allows one to zoom into the individual details while keeping the overall technology strategy in mind. As a CTO, you must know the vision for the company’s IP. You must avoid being pulled down into the weeds and stay at a high enough level to maintain the strategic level vision.

‘Technology’ or ‘Technical’ is the obvious part of the job description. The CTO needs to understand the technology. But there’s actually more to it than that; The CTO has to have the ability to share his opinion while engaged in any major business activity.  The CTO is someone you do not want to have hidden in the basement, but rather someone to have front and center applying the technical vision of the company. It’s important for the CTO to be able to project that technical vision on the spot, by going into a meeting or strategic discussion either internally or externally, be hit with a new set a parameters “Would this work with x?” or “Would this work with application y?” and, at the drop of a hat, have a sufficiently broad understanding of the technology and operating details to not only answer the questions but extrapolate: “Yes, and this is how we’d do it.”  That kind of knowledge is unique, and as your company reaches any kind of scale it becomes more difficult. The ability of a CTO to do that will give you the ability to advance the development agenda by leaps and bounds, not just by setting a direction, but responding well to shifts in the landscape. Nothing restores more confidences in a strategic partner or investor than a technical leader who can, not only articulate what has been done, but seems to have a clear command about what needs to be done in the future given the variability and uncertainty of that future.

“Officer” means liability and responsibility across the organization. Like a board member there is a certain amount of governance required. The ideal CTO should know the business strategy and operational strategy to an extent where he can be a functional participant and contribute outside the technical domain to the executive. CTOs use knowledge of the technical domain to inform strategic decisions while understanding and being comfortable with the other core areas of the company. Ideally the CTO should be able to take over core preparations, engage, and possibly close a commercial relationship while stepping in for the CEO. Having these skills makes one a much more effective CTO.

People Management , , , , , ,

Gaps in the Research, Development, and Engineering Chain

4 Comments Posted by on January 10, 2012

I talk a lot about bridging the ‘technology transfer gap’, but there is more than one place where technologies fall to their doom in the development of a new product.  When you define each stage in the process (Research, Development and Engineering) you start to see that there are two clear gaps.  Between each of these stages, a risky transition occurs. It is not just a few outliers that fail to make each leap; it is the vast majority of inventions.  A big part of the reason for this is that very different environments work best for each stage of the R-D-E chain, meaning that technologies do not just need to transition between stages; they typically need to transition between organizations with different cultures and expectations.  Any “technology transfer” model needs to take both of these transitions into account. Let’s first briefly define the three stages.

The Research Stage. At the research stage, new ideas are proposed and tested, solutions to problems are sought or discovered, multiple ideas are combined, and inventions result.  The best macro-scale model that we currently have for this process is the university.  Universities provide the most open and free environments for research to occur, with by a wide margin the most financial resources ( Microsoft Research, probably the largest corporate research entity on the planet, spends about a billion dollars a year on research, which sounds like a lot, but it is still less than even a mid-sized university).

The Development Stage.  The task at the development stage is to rapidly risk-reduce an idea emerging from research (the process of innovation).  Outlier or extreme cases are considered, many of the scientific elements must be validated, and the fundamentals of how a new technology works will be tested and mapped out.  In other words, the technical risk of an invention not working are eliminated or largely brought under control.  This is what startups do best due to their focus, speed and flexibility.

The Engineering Stage. Products do not just need to have their technical risks resolved; they also need to be made.  That means designing the technology with aspects like cost reduction, manufacturing, production, shipping, and maintenance in mind.  Large companies, beyond any doubt, do this the best due to their economy of scale (at least in the case of hardware and similar scalable solutions).

With three steps in the chain there are obviously two transitions. And that’s where the trouble starts.

 Transition 1: Research to Development.  The usual problem in research to development transitions is that the open, loose form of universities (great for research) is a disaster for development.  In development you need focus, speed, agility, and risk money, none of which the university environment typically provides. Inventors, the most likely people to lead the technology’s development at a university, have far too many competing objectives and have much greater incentives and access to resources for basic research and invention then they do for development (for the most part).

At the same time, it is much more difficult to sell an undeveloped invention to a large company, precisely because their emphasis and strength is in engineering.   And that is assuming that universities, who are generalist by nature, are able to create and maintain the relationships needed with large corporate structures in specialized industries to pitch their inventions, and understand what the market need for these inventions is.

Transition 2: Development to Engineering. Development Startups face a similarly challenging cultural transition. At first glance that doesn’t seem to be the case. The skill set of startup developers is actually very attractive to big companies – at least in the early courtship days. Startup developers look dynamic, pro-active and goal-oriented. That is why big companies buy startups all the time.  After the acquisition, however, this beautiful vision starts to fracture a bit. Many of the best startup producers are hackers at heart. Product engineering on the other hand requires rigour, discipline and process – aspects that a startup will often deliberately suppress in order to progress faster, focusing on the key technical issues. Over time, “dynamic” becomes “can’t focus”, “pro-active” becomes “disruptive” and so forth.  That’s why most acquisitions ultimately fail.

 TandemLaunch Technologies’ mission is to improve the transition efficiency in the R, D, E chain in a way that is consistently beneficial to Canada (more on this in a future post).  We accomplish this by 1) identifying key researchers and inventions, 2) leading and providing the resources for the development stage of these inventions, 3) providing industry with a developed invention and the support they need for acquisition, and 4) keeping and creating jobs in Canada.

Technology Transfer , , ,

Invention, Innovation, and Entrepreneurship: Different processes, different people

2 Comments Posted by on October 25, 2011

Invention, innovation, and entrepreneurship are words frequently thrown around by politicians, theorists, and entrepreneurs alike to generally describe the act of bringing a product or idea into the world.  While easy to confuse, each concept is distinct and requires specific skills.  When it’s time to choose the right people for your startup, these distinctions are critical.   

 

Let’s start with invention.  Invention is an intellectual exercise in connecting the dots.  It’s the eureka moment when you connect multiple problem statements with existing solutions from other spaces, parallel or unrelated, and come up with a new combination of thought that solves the problem statement that you have discovered.  It is a mental event. 

Often the moment of invention is very clearly defined.  A perfect example is the genesis moment for the high dynamic range display concept that led to BrightSide. We had the idea to combine two LCD screens in series to effectively multiply their contrast. Unfortunately, each screen absorbed over 90% of incoming light so the dual layer was extremely inefficient. We had thought about using an array of tiny light sources instead of the first LCD, but couldn’t think of any device that could deliver millions of such tiny light sources. We brought in a researcher from a different field (image rendering vs. optics), and he showed us a camera concept that would overlay a blurry and an adjusted sharp image to get much higher dynamic range in image rendering.  ‘Eureka!’ – we could use the same blurry+sharp idea on the display side by using an array of big LEDs (1000x larger than the tiny light sources that we thought we would need). In that distinct moment LED TV as it is known today was born. That’s an example of a distinct invention you can file a patent on, and off you go.  An invention can also develop over a period of time when you’re working on something and you slowly realize the little pieces that make the system work better.  In the aggregate, you’ve actually changed some essential component of your system and have an invention you can file a patent on. 

An inventor is the person who synthesizes the problem statement and solutions into a novel solution that solves some unique problem.  This definition of an invention is completely indifferent to what you do with the invention afterwards; you can be an inventor and not have done anything at all other than the mental exercise. This type is common at universities, but innovators exist in university environments as well.

Innovation is an ongoing process of getting an invention to a point where it has an application value of some kind.  That doesn’t happen automatically, because technology is only useful if somebody uses it.  Unlike knowledge, technology doesn’t have any intrinsic value. If you discover that some distant object in the sky is a planet, that knowledge has some abstract value for humanity.  If you find a cure for cancer and it doesn’t teach you anything new about biology, or the human body, and is just a particular mix of stuff that works, then it has no value until it actually cures somebody’s cancer.  We need innovators, because technology needs to be used (this is why we do what we do). 

The boundaries around the innovation process are sloppy, but roughly include all the steps between invention and pre-commercialization, or possibly commercialization.  This is the period when you start thinking not just about your idea, but what you need to do to make it work in practical terms.  You experiment, you fiddle around, you find out that it doesn’t work on current computers, and you adjust it in some way to make it practically realizable.  In the act of innovation, you might also invent new things.  But equally important, you are going to generate a lot of practical know how.  This is where the bulk of value in a technology startup is created. This know-how is often hard to characterize, because it is the embedded knowledge in the heads of your people, but it is of enormous value to any acquirer. 

Startups are sometimes the point of invention, but more often than not they are created after the invention to act as innovation engines. 

The concept of entrepreneurship is separate from this. Entrepreneurship is about driving innovation in a constrained environment (e.g. limited money or time). Often this happens in a startup, but it’s perfectly possible to be an entrepreneur inside a large corporation if the constraints are in place. An entrepreneur’s job is not just to bring the technology to market, or to the commercialization stage; the job of the entrepreneur is to create and maintain the environment that allows innovation to occur (people, money, goals, etc.).  Unlike single person corporations or partnerships that do not have an inherent constraint, opportunity, or even desire to scale (doctors, lawyers, consultants, and other freelancers), entrepreneurs engage in an aggressive pursuit  of scale under conditions of risk. 1 

When we look at these definitions together, we learn something critical about the people needed for technology transfer.  First, you do not need an inventor as the CTO in your startup.  This is a mistake I see a lot of startups make. You need access to the inventor to get clarity on their thoughts, but that can take the form of a consultancy on an as needed basis.  What you really need is an innovator in your startup’s technical leadership role.  This is someone who has enough understanding of the technology and commercialization process to drive the technology from invention to commercial application.  If the inventor does not have the skills or know-how to be an innovator, your startup company will die (this is in my experience the number 1 reason for failure in startups led by university professors).

On top of this you need an entrepreneur who can create the environment in which the inventor can thrive (people, dollars, money, and infrastructure).  And while your innovator and entrepreneur might be one and the same person, it is important to keep in mind that both roles need to be filled.

 

1 I specifically limit my definition of entrepreneurship to startup or dynamic growth entrepreneurs – scale entrepreneurs – and exclude small business owners.

Entrepreneurship, People Management, Technology Transfer , , , ,

Setting a meeting on fire

3 Comments Posted by on September 14, 2011

A few years ago, during my first start-up adventures at Sunnybrook Technologies, a prototype fire taught me two important tech entrepreneur lessons: 

 1. Good entrepreneurs don’t panic.

2. Adversity is an opportunity, not a problem.

We had just finished the first prototype of what would become the world’s first commercial high dynamic range LED display: the venerable Zeetzen-5.

Today’s LED TV bring power to the very efficient backlight at fairly high voltage. That wasn’t possible for us in those early days. Lacking dedicated LED drivers, we brought 1400W up from two huge power supplies at 4 volts through a thick cables (the picture shows the base unit on the top right, main chassis with power bus in the middle and backlight unit on the right edge). 

The prototype was just finished, when we got a major strategic meeting with top executives at Kodak.  At the time Kodak was in the process of shifting from analogue film to digital, and they saw us as a potential major opportunity.  Dynamic range is a key issue for film, and we had created a digital high dynamic range which would be a great companion piece for them.  After some soul-searching about the state of the prototype, we flew to Rochester, excited for our first major commercial demo. 

After arriving in Rochester and meeting the executives, we set up the unit, started the demo, flipped the power switch and BOOM!  The whole room turned black.  There was the kind of nasty black smoke that you get when you burn tires and a flame shooting out of the unit.  Everybody got up in a panic, people were in the hallway and there was a fire alarm warning.  It was just a humiliating disaster.  We just managed to avoid a full scale evacuation of the whole Kodak research facility and got everybody back into the room. 

So what do we do now?  The instinctive response would be to slink away, cry a little, and write off the meeting.  Instead, we did what good entrepreneurs should do.  My partner just calmly took over the PowerPoint and said, ‘We’re just having some minor technical issues here,’ and gave the presentation.  Meanwhile, I opened the box and found that a strand of the metal cables had come out from the connection point and shorted against the unit’s case.  At 100 amps, the short instantly evaporated the insulation around the wire, and that’s where the thick rubber smoke had come from.  I thought, ‘I can fix this.’

Warning: Do not attempt this at home. I wish I could say that I was a training professional but at the time I was just an undergrad student with just too much hacker hustling energy. Electricity at this current *will* do very unpleasant things to you.

Step 1: The fuse on the power supply was blown, and we didn’t have spare parts other than little pocket screwdriver.  I took a metal bit from the screwdriver and popped it in the fuse holder.  Any good engineer will tell you that this is not something you should do (listen to them!). 

Step 2: I then tried to figure out how to insulate the wire.  The only thing I had available to me was a stack of napkins from the muffins on the table.  I took the napkins, made a little carrying hammock out of them, and put the wire inside.  I was able to hold the hammock with my hand and pull up the wires to keep them from touching the ground. 

So we went back to the demo.  I was giving the demo pitch, pointing with my right hand to the screen and illustrating all the different issues, while my left hand was behind the unit, hidden by the open box, holding this little napkin hammock.  I was praying hard that the wires wouldn’t short out again turning the napkin, and by extension myself, into another flaming contraption. It worked.  Kodak was duly impressed.

After the meeting, we drove from Rochester to southern Ontario, invaded the home of an old acquaintance of my colleagues, and used his tools for a slightly more robust repair of the unit – and then spent another few days doing fundraising demos with prayers on our lips. The show must go on!

Lesson 1: Don’t panic.  Things will go wrong in demos.  The best and only thing you can do is to take parts with you (more than a screwdriver – these days I travel with entire carrying cases full of nothing but spare parts).  Most importantly, when something bad happens don’t lose your cool, don’t freak out, don’t start crying, and don’t give up.  The reality is that you will only make it worse by panicking or giving up.  You have done your homework, traveled a long distance, and these people have booked time for a meeting with you.  You might as well salvage the meeting.

Lesson 2: I am pretty positive that Kodak’s take-away from the meeting was not, ‘These guys can’t build displays.’ They knew that the technology we were developing was complex and a world’s first with a lot of technical risk in the system.  I think what they took away was, ‘These guys know this stuff so well, they can field repair with a napkin and a screwdriver.’  When a big company looks at a start-up, that knowledge is much more valuable than your ability to make polished little systems.  Companies are not going to buy you for your polishing skills; they have plenty of those.  They are looking for deeply ingrained technical expertise. Technical problems actually give you an opportunity to demonstrate that expertise.  I still would not deliberately break demos during a meeting, but don’t be scared if it happens. For entrepreneurs, adversity is an opportunity, not something to be feared.

Demo Stories , , ,

Follow

Get every new post delivered to your Inbox.

Join 988 other followers

%d bloggers like this: