The Abstract Truth

Archive for August, 2007

Bug Labs: Details, Details, Details!

Posted by rbpasker on August 30, 2007

A week or so ago, I wrote about Bug Labs new personal hardware development platform. Today they put up details about the platform, descriptions of the first few modules, and screenshots of the Eclipse IDE support.

Lets look at the BUGBase:

  • ARM processor
  • 128MB RAM
  • LCD
  • Button controls
  • 1x USB 2.0
  • 4x serial ports (hopefully 230K)
  • Hardware MPEg-4 codec
  • Hardware graphics (no spec)
  • 10/100BaseT
  • 802.11b/g
  • Speaker
  • Battery

Its unclear how much non-volatile memory the device will have, but it will need at least a gig or two, preferably on high-speed removable media. I’m also hoping the device will have power-management capabilities coupled with sub-microsecond hardware timers.

The base will be available around the same time as the first four modules:

  • GPS
  • Digital Camera / Videocam
  • Touch-sensitive, Color LCD Screen
  • Accelerometer, Motion Sensor

The accelerometer is pretty cool, but I probably wouldn’t use up a slot for it, because in Q1 08 I’ll add one these modules:

  • Touch-sensitive, Color LCD – 2X
  • Mini-QWERTY Keyboard
  • Teleporter
  • Audio Speaker, Input/Output Mini Jacks

The teleporter has me confused. Being as small as it is, this teleporter will probably use old 60s-era Star Trek technology, rather than something newer, like the an X-Men-based mutation field. But still, the benefits of being able to get around instantaneously will outweight the fashion drawbacks of the 60s.

If you’re listening, Bug Labs, here’s my laundry list of modules for Q2 08 and beyond:

  • phone, including SMS/MMS, and 3G networking
  • a software radio for AM/FM/XM/Serius reception
  • TOSLink 5.1 audio for surround-sound A/V
  • IR transmitter/receiver for making a universal remote

I think my full-fledged all-in-1 PDA/iPod/Camera replacement will need 6 modules: GPS, cam, LCD, kbd, audio, and phone. Since the device only holds 4 at a time, I’m hoping the modules will be hot-swappable.

My first project will be a fully integrated, internet-aware, extensible PDA. I’ve already started thinking about the internal architecture for such a thing that would allow people to develop their own web-services aware PDA plug-ins.

Well, I’ve applied for the Bug Labs beta program. Let’s hope they have room for me!

Posted in startups | Leave a Comment »

A High-tech Entrepreneur’s Guide to Surviving Technical Due Diligence

Posted by rbpasker on August 28, 2007

The purpose of technical due diligence is to investigate the technical aspects of an investment opportunity. But tech diligence is done infrequently enough that few people get really good at it, and in the absence of being good at it, its worthwhile to have some guidelines. This survival guide just that: a guide. But a thorough reading should get you in the right mood, and if you prepare well, you’ll have a much better shot at “wowing” your audience. You’ll know you’ve done a solid job if the person you met with offers to invest himself or wants to join your advisory board!

There are typically two different kinds of companies I come across: true high-technology companies that have a unique technology that can be applied across many different markets, such as Tervela and Mocana; and vertical companies which use (often novel) technology to deliver their product, such Mint, a new personal finance site, and MedCommons, which makes it possible for individuals to take control of their healthcare records. I’m only going to cover technology product companies in this post, but many of the same lessons will apply.

Some people who conduct technical diligence sessions (or any diligence, for that matter) see themselves as gatekeepers, wherein every company starts out as a “NO!” until proven otherwise. But I prefer the “all students start with an ‘A'” method, which means that my job is to help them get through the process as successfully as possible, just like when interviewing a job candidate. Indeed, treat the diligence session like a job interview or an oral exam, with the except that your company and technology are as much under review as is team.


Set aside a day or two to prepare for your first technical diligence meeting. You’ll be doing research, gathering materials, preparing illustrative slides, and, perhaps most importantly, getting yourself mentally prepared. If you’ve ever taken an oral exam or made a thesis defense, the technical diligence process should be a snap.

    Know your audience – Find out who is conducting the technical diligence and what that person’s background is, including work history and technical background. Typically a VC firm will try to find someone who knows your business, technology and ecosystem (e.g., SAP or MSFT) well enough to do a good evaluation, but that’s not always possible. Sometimes the VC will get someone who built or used the current generation of the product you’re building. And if your product is in a narrow technical area (security, embedded systems, etc.) or in a an area that is highly regulated, the person doing the diligence will hopefully have that experience as well. In any event, be prepared to give your audience some education on the intricacies of your domain.

    Bring your “A Game” – Amazingly enough, some companies don’t send their technology leadership to a technical diligence meeting! I’ve had non-technical CEOs come alone, put up the architecture slide from his VC pitch, and proceed to echo the party techno-speak and provide shallow or uninformed answers. Always send your CTO, VP Eng, Chief Architect, etc., to the meeting, so you don’t waste time.

    Provide documents in advance – If you will be referring to documents (patents, whitepapers, etc.) or drawings during the meeting, provide them beforehand, but don’t worry if they’re not reviewed in advance. I prefer to have the documents before the meeting so I can brush up on the domain. Having to photocopy, email, locate, or thumb-drive documents can be a distraction and slow down the meeting.

Introduction: Company and Product

Remember, this is a technical diligence meeting, so don’t give a investor pitch. But you’ll still want to cover a few non-technical areas in the introduction.

    Company – This is where you get to tell your “garage” story. Keep it short, but a good human interest story is key to drawing your audience in. Include the genesis and evolution of your product, too. This is where you also review the company status: headcount, previous and proposed funding, existing investors and advisors, etc.

    Problem – In an investor pitch, you would explain the business problem you’re solving, but in a tech pitch, you’ll also have to describe your customer’s technical problems, such as scalability, latency, volume, complexity, etc.

    Your solution – This is where you have to be very specific about what your product does. If your product is a DBMS, for example, say, “we’re building a new kind of DBMS,” rather than “our product fundamentally changes enterprise corporate data management.” You don’t want to get into a game of 20 questions while your audience tries to figure out if “enterprise corporate data management” means ETL, BI, integration, or something else entirely.

    Business model – Describe how your product will be marketed and get sold (direct sales, OEM, VAR, etc), and how your company will get revenue (licenses, support, consulting, etc.) If you are in the commercial open source space, now would be a good time to talk about licenses.

Main Presentation

You have a lot of freedom here to describe your product, but there are a number of areas which you have to address:

    Technology – This will be the longest part of the discussion, and should be done top-down, starting with an overall architecture slide, and going through every piece of your technology. If applicable, also describe the technology from a historical perspective, including previous failed attempts to solve the problem, and the overall industry environment that now make the problem solvable (e.g., increased processor speed, new algorithms, or availability of wireless spectrum).

    Underlying Infrastructure – Explain all your underlying technology choices, including programming languages, databases, app servers, and other tools and technologies that are part of your solution.

    Defensibility – describe the state of the intellectual property (IP), including patents, trade secrets, prior art, and the legal status of the IP ownership, rights, or licenses. You can also demonstrate defensibility by showing how hard it is to solve the problem using some objective measure like complexity theory, amount of code, exclusive resources, etc.

    Compatibility, Migration, and Standards – since no product is an island, you’ll have to go through how your product fits into the larger picture from a compatibility standpoint (intranet, extranet, internet), how customers are going to migrate to your solution, and what standards your product will support or require. If you’re dependent on the work in standard bodies or if you are going to promulgate standards around the product, then describe that here, too.

    Competition – Not only will you have to talk about competitive products and competitive companies vying for the same dollars, but you’ll also have to address build-versus-buy, and the biggest competitor of all: inertia.
    Customers that have something “good enough” present a huge obstacle to the adoption of new products, so you’ll have to explain how your customers solve the problem today, and of course, what (technical or business) impetus will drive adoption of your product.

    Team and Staffing –Demonstrate the technical team’s credibility and capability. A “dream team” usually has a successful track record of building a similar product for a similar customer base, but not every company can make that boast. One “dream team” example is Michael Stonebreaker, who has successfully launched any number of new companies related to his research and scholarship in the database space, including RTI/Ingres, Illustra, and Streambase. Try to show as best as you can that your team has (yes, I know its cliché) “been there, done that” in your product area.

    You’ll need a slide with the technical team org chart showing 6-quarters of hiring projections across all technical areas, including development, QA, product management, support, operations, etc. Each box on the org chart should show that person’s expertise (“java developer for streaming server”, “Windows developer for desktop client”), rather than generic “engineer” titles. You’re trying to show that you’ve actually though through your hiring choices, so avoid the temptation to use the headcount spreadsheet from your financial presentation.

    If you are doing any outsourcing or relying on an open source community to compete the project, you should have a slide for that too.

    Roadmap – Provide upto a year’s product history, plus the next 6-quarters of future product milestones. Tie the product roadmap to the company’s business and funding milestones, and to your hiring plan. This last point is key to showing your audience that the management team is working in sync.

    External dependencies – Almost every product relies in some fashion on other products, such as databases, app servers, etc. But some products or companies are dependent on products, consulting, or manufacturing that are not “commercial off-the-shelf” (COTS). You’ll need to describe any non-COTS dependencies, what the risks and alternatives are, and the state of the relationship with your suppliers.

    Product Development Process – I like to get a sense of what kind of development environment will be in place because it is well correlated with product quality. The process discussion should include “methodologies” such as waterfall, scrum, XP, etc., but also the product management process, development processes/tools, bug tracking, testing, etc.

    Consulting, Support, and Training – although these are primarily business issues, if your product has special requirements in these areas, you’ll need to cover them, too.

Do’s and Don’ts During The Meeting

    Don’t Derail the Conversation – Non-technical people at these meetings should be introduced and say good-bye, and leave the discussions to the technical team. Having someone bring up extraneous points in a meeting so they can “add value” doesn’t.

    Don’t argue politics – If you feel really strongly about something, express it, but don’t get lured into a debate for or against any hot-button issues (open source v. Microsoft, Java v. Ruby, Spring v. J2EE, etc.) Its still your company and product and you get to choose whatever technologies will make it work, but you may still have to defend your choices. Do so with grace and respect.

    Don’t Snow – “You can fool some of the people some of the time…”, but you will hurt your credibility with anyone who doesn’t buy your story. I give higher marks to people who are up front about what they don’t know versus those who blunder through a poorly thought out answer.

    Assume your Audience is Intelligent but Uninformed – This was the best writing advice I ever got from a college professor, and it works just as well in presentations. Inform, don’t educate, unless asked, otherwise you might come across as condescending.

    Spark Discussion – Don’t expect to stand up and make a long-winded presentation, then finish with a Q&A slide. Invite discussion, have interesting and important digressions, go into detail, and ask your audience members question,and solicit their opinions.

    Use Pictures and Diagrams – Slides are an aid to your discussion, not your lecture notes, so weigh heavily towards pictures and diagrams, rather than endless bullets. Don’t use any type face under 30 points.

    Draw on the Board – I always take the chair closest to the whiteboard because I’m always drawing and illustrating. You should, too.

    Make a List of Open Issues – Email the answers the next day.

    ABC: Always Be Closing – This “sales” advice comes from The David Mamet play “Glengary Glen Ross.” Don’t wait for the last slide or the good-bye handshake to close the deal. Every thing you say and do should purposefully move you closer to a successful conclusion.

The Aftermath

When the meeting is over and everyone is standing up shaking hands, make sure you ask appropriate closing questions, like “Did we answer all your questions?” and “What do you think of our product?” Personally, I prefer to make a rallying statement (“I hope we can count on your support.”) versus a question (“So, can I count on your support?”), but that’s a style thing.

After you leave the meeting, research and answer any open questions via email. A thank-you note is nice, but don’t ask questions about when they the feedback meeting is, and can they please tell you the status of the decision-making process. Those are questions for the VC, and the diligence guy is rarely in a position to provide the answers.

By now, you should have a good idea of how to conduct a successful meeting. Ultimately, the product and technology should carry the day, but being prepared, demonstrating credibility, and showing that you’re an integral part of the overall management team will get you many extra well-deserved points.

Posted in work | 3 Comments »

File Under: Law of Unintended Consequences

Posted by rbpasker on August 23, 2007

Elizabeth’s sister Laura Crosta is a professional photographer (and director, and graphic artist, and photojournalist).

Her edgy, hyperrealistic images have appeared in Rolling Stone, on album covers, and in major advertising campaigns.

But she also does many personal projects, including the one she describes below. You can see this masterpiece about my underwear by visiting her site, and navigating to “Projects” > “Bob’s Underwear”.


Posted in personal | 2 Comments »

Reducing Risk in Software Development

Posted by rbpasker on August 21, 2007

Have you ever heard the expression, “Ready! Fire! Aim!” ? Scoping projects has a natural progression: (1) figure out what you’re going to do (2) figure out how you’re going to do it (3) then do it. Confuse the order, and your asking for trouble, like slipped releases, incomplete features, and poor performance.

All of these problems hurt the overall business as the company and customers lose confidence in engineering’s ability to deliver product. Confidence is inversely proportional to risk – less risk means higher confidence, and vice versa – so reducing risk in a release should increase its confidence.

One way I have found to reduce risk is to categorize projects or tasks into three risk categories – low, medium, and high – which follow the 3 stages above:

  1. high risk – tasks which you don’t know what to do or how to do. High-risk tasks might also be labeled research projects. There’s a grad school joke that research is the process of going up alleys to see if they are blind, and finding the right alley can take a long time. From a product defensibility standpoint, however, these kinds of features are great because they are notoriously difficult. But from a product delivery standpoint, these are schedule-destroying tasks. If you have research projects on your product schedule, there is significant risk of failing to deliver.
  2. medium risk – tasks which you know what to do, but not how to do it. The risk here is in how long it takes to figure out how to complete the task. This is one of the mains reasons why smart and experienced people are so valuable: they know how to do stuff.
  3. low risk – tasks which you know what to do and how to do them. These tasks are not necessarily simple or less complicated tasks, but they are ones which can just be implemented.

Reducing risk then becomes an exercise in turning high-risk items into medium-risk ones, and medium risk into low risk by answering the unanswered questions, and by dividing higher risk tasks into a number of smaller lower-risk ones. Preferably, this should be done outside the release cycle, but that’s not always possible. The release, then, includes only lower (although not necessarily lowest) risk items.

To convert a high-risk project into a medium risk, you have to know what you’re going to do to solve a problem. For example, imagine you have a system that process 100 transactions per second, but you need to increase throughput to 200 TPS. There could be many different ways to achieve this goal, such upgrading systems, adding disk spindles, partitioning the application, implementing a SAN, converting from a scripting language to a compiled one, or some combination thereof. Say, after a month’s worth of research and experiments, you decide that partitioning and converting to a compiled language are going to have the greatest impact. You have now converted a high-risk task into two medium-risk ones.

To convert a medium-risk task into a low-risk one, you need to answer the question “how?” In our example, we have “partitioning” and “compiling,” so then you have to figure out how you are going to partition the application and what techniques you might use to convert your scripting language to a compiled one. A number of additional experiments might be in order, and you might also evaluate helpful third party products. But at the end, you have to know pretty much what you’re going to do, and create a new set of low-risk tasks to complete the project. The better you define how you’re going to do something, the less risk there is.

Reducing risk is not an exact science, but what I’ve tried to do is create a paradigm which you might adopt to your own work habits, whether you’re running a huge engineering project or you’re working on your own. Doing what you say you’re going to do when you say you’re going to do it gives you great credibility among your colleagues, and its also a huge confidence builder. Identifying and reducing risk is a great way to achieve it.

Posted in work | 2 Comments »

Please Resubscribe

Posted by rbpasker on August 19, 2007

I just realized that WordPress, unlike Blogspot, doesn’t allow <LINK> entries to redirect RSS subscribers to my Feedburner feed. If you are subscribed via a WordPress URL (or are not sure), please resubscribe using this one. Thanks!

Posted in net | Leave a Comment »

“Hi, My Name is Bob, and I’m a Hardware Addict”

Posted by rbpasker on August 19, 2007

I am addicted to hardware. Not gadgets, per se, although I have too many of those collecting dust, too. I mean that I love working on hardware projects.My first exposure to hardware was in my teens, during the 70’s home hobbyist years that launched the PC industry, when I read read and re-read magazines such as Byte, Kilobaud, and Creative Computing. But I soon realized I had no talent for building stuff, having failed at basic skills such as soldering, breadboarding, and socketing ICs (I’m sure I kept more than one EEPROM manufacturer in business from all the pins I bent).

Career-wise, I also started working on hardware projects early, contributing to a VMS device driver for the DV11 Communications Multiplexer (34 meg pdf) in ’83. Since then, I’ve written embedded software for a number of hardware projects, including the Opcode Studio 4, the TribeLink8, and the Sun HSI/S, and I’ve been involved in a number of hardware and embedded systems software companies, including Azul Systems, Rapid Logic, db4o, and Tervela.

Over the past few years, I have been elated to see the resurgence in homegrown hardware, evidence by the success of Maker Faire, Make Magazine, and Make Blog. But even those projects require handicrafting skills I don’t possess.

Last week, however, I may have finally found the solution to my quest to design and develop my own hardware devices. I attended happy hour at the Bug Lab‘s first Bug+Bar, the first of many buzz-building geek fests presaging the launch of Bug Lab’s new product.Bug Lab's What you see in the picture (thanks Make) is the “bug” (bottom), a camera “module,” and an accelerometer “module” (top). The Bug itself is an approximately 4″x 2″ ARM-based system running Linux and Java that lies at the heart of Bug Lab’s vision. These two Modules are among the first of the Bug’s peripherals, which plug into one of the four Bug sockets. The hardware vision, at least, is to build one’s own portable devices, without requiring any more hardware skills than someone like me possesses. Support is planned for USB and other device interfaces. I believe they are are also going to provide the specifications for the modules themselves, so that you hardware developers can build your own.

Beyond the Mr. Potato Head-style hardware is an software suite based completely on GPL’d software, and the developer’s kit will come with source code for the entire Bug and Module stack. Applications can be written in Java, and there will be Java library support for all of the Modules, so you can control the devices from your embedded application without writing drivers.

From a tooling perspective, there is Eclipse support, and the ability to run and debug on your own machine, before loading your app on the Bug. The big difficulty with developing for embedded systems is the workflow, and I hope Bug Labs will pay a lot of attention to end-to-end developer productivity.

I heard a lot of tastier details, but I’m going to leave those for the official launch. My 30-year quest to build my own stuff may finally be coming to a happy ending. I can’t wait to get my spastic little digits on one of these devices.

Posted in work | 2 Comments »

A New Chapter

Posted by rbpasker on August 18, 2007

Congrats to my friend and colleague Dave Rowley, who is taking over engineering and product management at Kiptronic. I found out what a talented manager, technologist, and product guy he is when he worked for me at Kenamea, running client engineering. He then moved up to VP Engineering, took over product management, and eventually left to join SNOCAP, a music licensing management service provider.Through legal, regulatory, and economic pressure, the entrenched music industry makes it nearly impossible for music startups to turn a profit, even as consumers flock to sites like and, the ad insertion business has a brighter future, as the supply of ads continues to outstrip places to put them.Good luck, Dave!

Posted in work | Leave a Comment »

My first post on the internet

Posted by rbpasker on August 17, 2007

According to Google Groups my first USENET post was on 24-March-1989 from my account at RTI (AKA Ingres).

I had moved to California from NYC just the month before.

Path: utzoo!utgpu!!mailrus!!EDDIE.MIT.EDU!think!rtech!bunny::pasker
From: think!rtech!bunny::pas...@EDDIE.MIT.EDU (Bob Pasker, X2434)
Newsgroups: gnu.emacs.bug
Subject: Gnuemacs
Message-ID: <>
Date: 24 Mar 89 03:29:23 GMT
Distribution: gnu
Organization: GNUs Not Usenet
Lines: 10

Mail seems to be the only thing I know how to use on the internet.
How can i fetch a copy of the latest GNUEMACS manual from your node?
Can you just mail me one via the internet?Any help would be appreciated.

thanks, bob pasker

Relational Technology
VAX Development

Posted in net, personal | 1 Comment »

How Much Capital should we Raise?

Posted by rbpasker on August 17, 2007

Raising capital for a startup is a difficult process. How to do it well is probably one of the most frequently asked questions. Even the most prolific CEO will only raise money 10 or 15 times in a career, while professional investors (AKA VCs), on the other side of the table, do it every day, all day, and work in an office full of people who also do it all day, ever day, so its no wonder founders and CEOs are always looking for good advice.

There have been numerous treatments of this topic, but I would like to focus on one blog entry by Don Dodge (albeit on a different topic, which I’ll cover separately), because he makes a number of very good points that are worth exploring further.

1. “the key is to have several VCs or investors competing for the deal”

This is indeed a key point, and not just because it provides a better bidding situation for the company. There are a many tactics used by VCs to bump competing VCs from a deal, and fund raisers need to have two or more horses in the race, right down to the wire. One tactic is to provide a very favorable term sheet “subject to due diligence” early in the process and get the CEO to drop other VCs. Then, after the lengthy due diligence process, the VC says “the company is not as far as we thought it was”, and proposes new, onerous terms, such a lower valuation or a full ratchet. If you don’t have other VCs in the wings, you might have to either take the deal or restart discussions.

2. “Companies fail because they run out of cash…they usually don’t fail when they have too much cash in the bank.”

Every startup starts out with no money, until someone puts money in. That money can come on day one from the founders, from angels, from VCs, or from a spin-off. Nevertheless, the money gets invested throughout the life of the company because investors believe in the company vision or because they agree to the risk/reward. Once existing or new investors lose faith in the company (for whatever reason, see #3 below), the money dries up and the company eventually either turns a profit, gets sold, or runs out of cash. Undercommit and overdeliver on your (mutually agreed upon) milestones, and you’ll keep the investors happy, and you won’t run out of cash.

3. “How much money should I take? … My simple answer is a little more than you need to reach the next milestone.

What should that “next milestone” be? As you are talking to potential investors, listen very carefully to those who turn you down (if they have the guts to do so at all), because often times they will implicitly tell you what milestones you need to reach in order to get back in the door at the valuation you are proposing. I call these “fundable milestones.”

Some of the most common milestones are: product maturity (beta, production, some set of features), revenue/spending/hiring targets, CPC/CPM/CPA, uniques/adoption rates, or marquee customers. These targets could also be expressed as a rate, e.g., “50% increase in uniques per quarter.”

So the answer to “how much money?” is, then, more than enough to achieve the milestones that will get you back in the investor’s door at a valuation that you are willing to accept. Give yourself some buffer (3-6 months of operations, depending on how close to the edge you’re willing to go), but don’t raise much more. You don’t want to be running out of cash with your next fundable milestone still ahead.


Posted in startups, work | 2 Comments »

Facebook for the Enterprise

Posted by rbpasker on August 17, 2007

The internet is full of surprises. Just when everyone thought MySpace was the killer personal social networking platform and LinkedIn was the killer business social networking platform, along comes Facebook, and we realize that its still a horse race.

We saw this happen the web app space when Cold Fusion eventually gave way to WebLogic (eventually giving way to other J2EE platforms; CF now runs as a J2EE plug-in), and search “giant” Alta Vista was run over by Google. Now, it seems, J2EE and Google are perceived as being vulnerable to LAMP/P/R and lightweight Java frameworks such as Spring, and to semantic web startups like Powerset, respectively.

I’m not going to jump on the Facebook versus MySpace war, since that has been covered extensively, but I do want to point out one glaring difference: Facebook has a development platform and MySpace doesn’t. Ever since my first infrastructure software project, I’ve relied on plug-ins to permit customers to extend the platform. On VAX/VMS, it was hard, but in Java it was pretty easy. When making a decision about which kind of product to use, smart, creative people pick extensible products because such products are a canvas that they can paint and interact with, rather than just a painting to be hung on the wall. Plugins are found in all sorts of products now, such as Adium, Eclipse, WordPress, etc.

What does this have to do with Facebook for the enterprise? Well, Jive Software’s Clearspace, which bills itself as an Enterprise 2.0 collaboration product, can also be thought of as an enterprise social networking platform that allows employees to get to know each other, share data, and collaborate through the use of wikis, blogs, instant messaging, and file sharing. Jive recently launched its developer program to provide a marketplace of plugins for developers and customers, and they are now holding a plug-in contest with a $5,000 cash first prize. The advent of plugins for Clearspace means that they are poised to provide Facebook-like extensible functionality inside the firewall, no doubt over the objections of their more static competitors.

(NB: I am an advisor to Jive Software)

Posted in startups, work | 1 Comment »

%d bloggers like this: