Fund the Answer, not the Question

Some of the most common founder questions revolve around the timing and size of funding rounds. These two components are interconnected. After all, if you raise a large round, you likely won’t need to raise again for a while.

I find that the best way to structure the size and timing of a startup’s financing is to “fund the answer”. What the “question” is, depends heavily on the industry, stage, type of technology and market, and the startup’s needs itself. The founder has an investment hypothesis, or a question, about the future of the startup, and the investor finances the answer to that question. For example, a very early stage R&D-heavy startup developing something revolutionary will have the question “Does it actually work”? or: “Can we even build it?” In this situation, the founders and the investors partner up to answer that question. If answered affirmatively, you have a Proof of Concept. The funding required to test the hypothesis of “We can build it”, may be small or quite large. Again, it depends on many variables, namely the technology and how revolutionary it is (how much further advanced it is from the current state of the art).

As another example, consider an eCommerce company. Such a new startup doesn’t have at its core a question such as “Can we build it” (the required tools have been standardized for over a decade) but rather evolves from marketing-centric questions: “Will people purchase off our webshop?”, then “Can we acquire customers cheaply enough to make a profit per transaction”, then finally “Can we scale above $10mm in revenue?”. Each of these questions represents different phases of the eCommerce startup’s growth, and require different funding amounts (and likely different investors) for each of the periods.

So the right amount of funding is how much is required to answer the question, and the right timing is how much time you’ll need to do that.

Many times pitches sounds like the company is looking for financing without a clear idea of what question they are addressing. In this cases, it sounds like the financing itself will be used to buy time for the company to figure out what the question should be. This implies a lack of strategic focus. This becomes clear when the company is showing promise, but the management is not clear about what the next steps should be. Founders should always be considering the next step and can firmly articulate their strategy showing exactly what the financing should accomplish (according to their hypothesis). Fund the answer, not the question.

This way of thinking has the added bonus of helping to identify the right investors. If you address investors that don’t care about the answer or the question (because it’s not their area of focus or stage of focus), these investors won’t call back. Try to identify investors who want the answers to the same questions you do. These are the right partners.

 

Image credits:
Flickr//User: ed_needs_a_bicycle

Rassberry Pi Remote Controlled Car- Step 2: Breadboarding

car_control_bb

 

Bread Board Prepping - 4 GPIO ports are used to control forward, backward, left, right

Bread Board Prepping – 4 GPIO ports are used to control forward, backward, left, right

 

Raspi Car Control with Pi Cobbler

Raspi Car Control with Pi direct connect
(I cut the hazardous GPOI pis from the circuit to ensure I didn’t short the Raspi)

See also:

Rassberry Pi Remote Controlled Car- Step 1. Reverse Engineering the Car

Rassberry Pi Remote Controlled Car- Step 3. Schematic and Stripboard

Rassberry Pi Remote Controlled Car- Step 4: PCBs

 

 

 

 

 

Rassberry Pi Remote Controlled Car- Step 1: Reverse Engineering the Car

I picked up a small RC car, about the size of a matchbox, today and have decided to reverse-engineer it in order to have my Raspi control the car remotely. The idea is to use Pygame or some other python library program to control the car via the GPIO pins.

The RC Car comes in a “coke can” packaging and is only 10€.

The car, with and without its plastic cover.

It’s a pretty simple controller. I choose the car for its simplicity since unlike most RC controllers; this one’s controls are simply on/off push buttons. Most of the time RC Car manufacturers use analog potentiometers in order to give the user speed control as well, but this 10€ model only allows the user to determine if it goes forward/backward, no control of how fast. That makes it much easier to control, since we can replace the pushbuttons with transistor logic.

After taking the controller apart, I establish that all 4 (left, right, forward, backward) pushbuttons result in voltage going from 0 to just over 3V, with very little current on closed position. This is great, since we can power the whole controller from the 3,3V pin on the Raspi (I decided the voltage was within tolerances so did not need to be stepped down.)

The bare PCB board of the controller.

See also:

Rassberry Pi Remote Controlled Car- Step 2. Breadboarding

Rassberry Pi Remote Controlled Car- Step 3. Schematic and Stripboard

Rassberry Pi Remote Controlled Car- Step 4: PCBs

 

Overcoming Android Maximum Resource Size

HTGF Connect LogoI recently developed two android apps to help my colleagues and I at HTGF manage our large portfolio and investor network. The apps are pretty simple, just a search field and a list of results, with the relevant information displayed when you select a contact or startup (contact details, company history, etc). The problem was, I planned to import both the contacts and the portfolio list SQLLite databases, but each had so much information that the resulting DBs were about 5MB each.

Android compresses Resources and Assets in order to make the resulting APK smaller, but it imposes a 1MB limit (I’ve heard this is larger now) to what it will compress. Any file larger, and the Android Asset Packaging Tool (aapt) refuses to compile/build the APK.

For most developers, this is not a big deal, since typically you wouldn’t want to have that size Assets anyway since you’d preferably keep the DB up to date on a server and have it update the App information when called. But there were two problems with this for our internal use-case: i) we wanted it to work offline, and ii) for data security reasons we weren’t going to put any confidential startup information on an internet-accessible server (the security audit would have been so much work we’d have rather just not had the app). So installing the DB as an Asset within the APK on the initial installation was the only way to go.

I eventually discovered that there are some file types which aren’t automatically compressed during the build, specifically files that have already been compressed or do not compress easily. “.JPEG” is one such file, so the easy solution was to rename the SQLLite DB to “database.jpeg”, since SQLiteOpenHelper doesn’t care what the file is called so long as it’s consistent.

Since then, I’ve been able to use much larger assets simply by called them X.jpeg instead of their normal extension and aapt assumes they are already compressed files. No problems, they are simply built into the APK as is!

8 bit Arithmetic Logic Unit (ALU)

After previously building the NAND, Full Adder, Full Subber, and Comparator, I felt ready to tackle the Arithmetic Logic Unit (ALU). Since I’m not certain exactly what opcodes and microcodes I’ll be implementing later, I wasn’t sure which functions to include in the ALU. Working off of the list of operations from the 16 bit ALU from Warren’s Microcoded CPU, I decided on the following 20 operations: addition, subtraction, multiplication, division, remainder, negation, greater than, equal to, less than, AND, OR, NAND, NOR, NOT, XOR, Logical Shift Left, Logical Shift Right, Logical Rotate Left, Logical Rotate Right, and Arithmetic Shift Right. There are some extra slots on the MUX available in case I need to go back and add some operations later.

There’s a flag output for carry_out and borrow_out from the addition and subtraction operations. I decided against including the in and out flags for the multiplication operation for simplicity’s sake and may need to come back and include that later if the micro-codes require it.

(Click on image for higher resolution version).

8 Bit ALU

 

Home-brew Computer Step 3: D Flip Flop to Memory

Now that we have 1 bit of memory, it’s pretty simple to build that into something more useable.  By putting 8 D Flip Flops together we get 1 byte of memory.  If we double that and add an address bus, we get 2 individual bytes of addressable memory.  I could go on but I think two bytes is enough to demonstrate usage of both the data and the address buses.

The address bus is simply 1 bit in this example. 0 means we’re addressing the top 8 bits of data, 1 means we’re addressing the lower 8 bits of data.  Doubling this and having 4 lines means 00,01,10,11 or 2 bits of addressable memory, each of which is 1 byte (8 bits).

Typically you would control the read/write* with only 1 bit: 1 means read, 0 means write, but for clarity I have two data buses here: one for input (the 8 bit bus on the bottom of the diagram), and one for output (the 8 bit bus on the top of the diagram).

On the bottom left I have some non-relevant components that I used for testing the 2 bytes of memory.  The clock is obviously necessary, but the rest are: a Logisim random number generator (8 bits)  to fill the addressed 1 byte of memory for testing, and a 8 bit LED output for testing the output data bus.   There are 3 1-bit controls: an on/off for the clock signal, the read/write* control bit, and the 0th / 1st byte switch for testing the address bus.

 

2 Bytes of RAM from D Flip Flops

2 Bytes of RAM from D Flip Flops

Home-brew Computer Step 2: Gate Logic to Memory

For anyone familiar with flip flops, persistent memory in circuits can be achieved with arrays of flip flops (typically clocked D circuits).

For my circuit I’m taking 6 NAND gates (all but one with 2 input values, and 1 with 3 input values) and co

mbining them with the clock for a D Flip Flop / 1 bit Memory circuit.

D Flip Flop Circuit / 1 Bit Memory

D Flip Flop Circuit / 1 Bit Memory

Home-brew Computer Step 1: Transistor to Gate Logic

To simulate a home-brew computer from the smallest discrete components, I’ll start with transistors, resisters, and a clock signal. We could go smaller and make the clock from a RLC network (resistor, inductor, and capacitor in series), but that would require a simulator other than Logisim.  While there are several methods of going from transistor to gate, my example is based on Resistor-Transistor Logic.

Since it’s possible with De Morgan’s laws to change any NOR to NAND or NOT and vice versa, I’m limiting this exercise to only NAND gates (it’s also easier with the transistors I’m simulating).

Transistors to NAND

NAND Gate from NPN Transistors

Since Logisim doesn’t have components for resistors, instead of coupling resistors to the ground and power sources (necessary to avoid shorting the wire if both transistors are allowing current), I am instead connecting a pull-up transistor as the source and a pull-down transistor as a sink.  The transistors used were NPN type (and while I don’t think it makes a difference from a logic standpoint, the icon implies they are MOSFET).

Running through the truth table for a NAND gate confirms the above circuit.

You might be wondering why we don’t just connect power and ground instead of the pull-up and pull-down resisters.  It’s because doing that would short circuit the network if both gates were allowing current, since it would flow directly from the power source to ground.  Not only is shorting bad, but it gives an error as output, since it’d be a floating (unknown) value.  Using the resistors ensures that the output value is either pulled high to True or low to False in all scenarios.