Tag Archives: User interface

Perspective on Pitching

by in My Startup, , 7 Comments

Having been at the ground floor of a startup before I’ve experienced writing the first lines of code, shipping a product, and then getting acquired, but I never had the experience of pitching or seeing someone else do.  Last Wednesday I did my first pitch for my startup, BizeeBee, in front of about 75 people, a panel of 4 angel investors, and alongside 7 other founders.  While this might seem nerve-wrecking to most, it was an experience I had been looking forward to for months.  I finally felt like a founder!  The event was sponsored by DukeGEN and limited to founders from Duke.

The reason I really liked this format was that before the founders presented the Angels took the time to tell us what they were looking for.  Each pitch last 6 minutes and there was a 3 minute Q&A period following each founders pitch.  Before announcing the winners,  the Angels spent time giving each business feedback, which I found to be extremely valuable because I got to experience first hand how they evaluate and think about business ideas.

Here’s what the angel’s were looking for:

  1. Getting to the heart of the product and what problem it is solving
  2. Large market
  3. Explanation of Customer Acquisition strategy
  4. Team: strong technical and business members
  5. Polished presentation and understanding of each component of your business

Here’s what the Angels focused on during the QA and it making their final decisions:

  1. Many of them questioned the actual market size, and drilled into the numbers presented.
  2. How robust the technology was compared to competitors, and if it was enough of a differentiator.
  3. How much of the product had already been built out.  Having an actual prototype versus a PowerPoint presentation was more powerful.
  4. How capable the founding team was of executing on the business and technical side.
  5. Traction and having customers that were using the product.
  6. The methods used for attracting customers.  Angels really care about your distribution model.

I came in third place.  Here’s the feedback I personally received (yes I’m still leaving my readers in the dark about my product):

  1. Great team, brand, UI, and simple product proposal.
  2. Given that I’m targeting the SMB space, they were concerned about how scalable my business model is given how fragmented of a space I’m operating in.
  3. They did emphasize the need for a couple more key hires such as a VP of Engineering and VP of Sales.
  4. Traction – they’d like to see the customer feedback, how the product and brand awareness will spread, and if I’ll be able to start making money off of customers.

One final note, I want to thank my teammates Liz and John for all their support and hard work that went into helping me prepare the prototype and the pitch!  I couldn’t have done it without either of them 🙂

Enhanced by Zemanta

Freemarker Browser Issue with Date Formatting

by in Software Development, , , , , , , One Comment

When I have to write an internal tool I use Freemarker as my templating engine of choice, because in one file I can write html, and then access Java objects that are passed in a model. Its faster to use for development than engines like Velocity or XMLC, and has enough functionality to write the UI for a tool. The Java objects values are resolved using reflection, to either Strings or Integers.

Recently I ran into a browser compatibility issue. When I used the following code

<#assign currentDate=myObject.todaysDate?date?string.short>

<td>${currentDate}</td>

The dates would render the current date but in the wrong millenium only in Firefox.

The solution is to instead do the following:

<td>${myObject.runDate?date}</td>

The correct date is printed.  The format is month name, date, and year, and it also contains a timestamp.

Enhanced by Zemanta

Presentation for Code Camp ‘08

by in Software Architecture, , , , , , , 0 Comments

I will be giving a presentation at Code Camp in about one month. The title of my presentation is “The Evolution of a Scrappy Startup to a Successful Web Service”. In the following posts I will attempt to flush out some of the ideas I plan on presenting. Please feel free to comment on my ideas and provide feedback.

Part I: Prototyping

I remember Mint’s alpha launch as if it were yesterday even though it was almost two years. The main purpose of our launch was to get a prototype out for our friends, family, and investors to try out. We had pinned down our mission statement: “Mint: do more with your money.” We wanted to convey this message in our prototype. Thus, the feature set we chose was deliberately limited. Our main feature set consisted of showing users their transactions, and aggregating the balances of their checking and savings accounts, that was it! Nothing more nothing less. Why? Because the basic definition of a prototype in software development, is a rudimentary working model of a product or information system, build for demonstration purpose or as part of the development process. We planned on developing more features, but we wanted to demonstrate what we were going to do as a product. Starting out with a small feature set and growing it from there was the best way to go.

1. How did we arrive at this feature set? We started out by flushing out what was going to differentiate our product from the rest. Account aggregation, showing people their checking and savings accounts and categorized transactions on one web site.

2. What doesn’t belong in prototyping? Everyone wastes time trying to spec out a complete feature set, and all the bells and whistles they’d like to have in their product. We tried to limit that process. Once we had pinned down our feature set we went from there. The first step to prototyping is to figure out what the critical problems are that we are trying to solve and will encounter in trying to solve them. Since we were a financial web-app we had to handle security, and some concurrency amongst our 100+ users. We also had a few algorithms that we were implementing that drove our business differentiation, but none of these were completely flushed out. We coded up the bare-bones implementation for each of these. We also set up a simple unit test framework, but nothing too fancy and no system tests, because the focus was to get the product out there and have real users test it with real data!

3. So what did we it look like? Our prototype consisted of several Java modules but no real architecture, because we only had a couple hundred users and less than a handful of engineers to build it. So we made due with what we had. But we had good separation amongst our modules in terms of separating the core business logic from the data processing engines, and the UI from the server side logic.

Enhanced by Zemanta