Posts Tagged: best practices

posts — 2 Comments
10
May 10

DreamIt Ventures Kickoff Weekend – 2009 cohort panel on lessons learned

DreamIt Ventures

This weekend was the 2010 DreamIt Ventures Kickoff Event in Philadelphia. It was great to see 15 new startups in the Philadelphia area, buzzing with activity and ready to get started. The kickoff events were held at the soaring Comcast Center on the 45th floor, an exciting venue that helped amplify the energy.

Lots of folks from the Philadelphia startup community attended and there was a ton of good advice dolled out to the incoming companies. Two segments of the weekend, in particular, captured some good lessons for the 2010 DreamIt companies. I’ll recap these from my notes in two posts.

The first segment that I want to summarize was a panel session with three companies from the 2009 cohort: Jack Groetzinger from SeatGeek.com, DJ Stephan from Notehall.com, and myself for FanGamb. Clearly, having been on the panel, I’m a bit biased, but I felt there were a lot of good points made.

A summary of some of the important takeaways from the panel discussion:

  • There’s more than one way to build a startup.
    • SeatGeek launched at TechCrunch 50 and raised a good sized series A VC round.
    • Notehall.com was featured on ABC’s SharkTank program in October and closed a moderate seed round.
    • FanGamb closed a family & friends round in the fall to continue iterating the core game (something larger in the works that can’t yet be disclosed).
    • The message: There are lots of different funding options. Find the one that works for your business. Raising VC funding isn’t the only definition of success. The longer you hold off on raising funding and the less you raise, the more options you keep open and the more ownership you maintain, generally. Another point by Jack: when raising funding, put one person in charge of the process and send him/her to the meetings only – don’t let the process distract your entire team, keep them focused on building the product.
  • Don’t be afraid to pivot.
    • SeatGeek grew out of the largest pivot from DreamIt ’09. The founders, Russ D’Souza and Jack Groetzinger, were accepted to DreamIt with an entirely different business – Scribnia.com, a blogger review platform. They sold this business in June 2009 and built the SeatGeek prototype in 1.5 months in time for Demo Day. The message: no matter what pivot you’re considering, it’s not bigger than changing your business entirely, so keep all options open.
    • Notehall changed the way it sold notes at campuses. Originally, it gave notes away for free to kickstart the market, but advisors were suggesting they try another model. Finally, after months of ignoring this advice, they finally piloted a different model and found it to be hugely more successful. The message: be open minded – the DreamIt partners and your mentors may not know your market specifically, but they know how to grow businesses. Be true to your vision, but be open to trying other models.
    • FanGamb pivoted with regard to two aspects of its model – how to drive engagement and its business model. Regarding engagement, a key assumption was that badges and leaderboards (i.e. social proof) would be enough to drive users to be engaged with the site. To a point this was true, but never to the level expected. Similar, virtual goods were expected to be a key monetization engine for the site, however, without the high levels of engagement, this wasn’t effective as a first step. As a result, the FanGamb team tested multiple options and is in the process of implementing a new model (again, no specifics currently – news coming soon). The message: get your core user base using the product as soon as possible, throughout your iterations and test your user acquisition methods, too. We wrote off early user behavior because we were testing with a different sport than we would launch with in the fall, but in retrospect should have taken a harder look at the data.
  • What do you think some were some of the key factors that led to your companies succeeding, versus those that didn’t from your DreamIt cohort?
    • Don’t die – find a way to pivot. In nearly every startup concept there is a nugget of truth/value – you need to distill your concept down and figure out what that is as quickly as possible and make course corrections along the way. Startups are a process of going down as many dark alleys as you can before you run out of motivation and money.
    • Get real customers using the product as soon as possible and find out what they really think. (Side note: it was amazing how many of the DreamIt startups talked about the status of their customer development efforts in parallel with their product development efforts in their overview/status talks – quite a change from a year ago, really showing how the lean startup methodology has taken hold. Seems to be effective lean startup, too, not lean washing…)
    • Solid, stable teams that put in a ton of hours (the three companies on the panel represented teams that put in some of the most hours throughout the program – SeatGeek put in 36+ straight at one point, winning the prize for the most time in the office) — this wasn’t specifically mentioned during the panel, but was an observation we noted afterwards

Certainly lots of good thoughts and lessons learned from the panel. More great thoughts and startup advice from Steve Barsh’s Kickoff presentation coming in a future post.

posts — 1 Comment
7
May 10

Three lessons learned from my early days of releasing software

The other day, I received a call from a user of one of the software products I developed, back when I was running my own web development consulting firm, Shedd Technologies International. In addition to doing pure client work, there were several products that I packaged up and made available for use – some as freeware, some as commercial software. It’s been many years now since the products were actively developed and I was impressed to hear that they’re still proving to be useful.

The call provoked some thought about what I learned from the process of developing and supporting a set of packaged software products. This is a fairly long post – it’s part reflection for me, though I would think it would be also be potentially useful to any other young entrepreneurs looking at building software products.

We all have so many different experiences in our professional and personal lives. It’s really only after these are over and after you look back that you start to see what you learned from the experiences. There’s certainly a lot of value that you can get out of taking a look back, though, and this is a process that I’m going to try to do fairly regularly going forward. Especially with startups, the day-to-day is so crazy, I think it will be useful to take a step back every 6 months or so to reflect on what we’ve learned, what worked well, and what we can improve upon. But for now, here are some reflections and lessons learned from the start of my career with technology on the web…

 

Background

First, the background:

Not long after starting consulting work, some client project work led to several pieces of software being developed, which lent themselves to release as packaged products. For a site needing a photo gallery, I developed the code that became a simple script called PhotoGal. Another client needed an affiliate management system and this was extended into Affiliate Manager, which was because a commercial product that I sold under a consulting model – base license fees + fees to install and adapt it to your individual business. There were also two products other products developed, as well, which were not extensions of consulting work. Support Services Manager was created as a helpdesk tool for internal use, but was released and really only used by external users. DLMan, a digital product delivery system, was perhaps my most concerted attempt to develop a packaged product.

There are a lot of lessons that I can pull from this work. As a whole, my software products were moderately successful, depending on your metrics. While it’s hard to estimate the actual installed base, Support Services Manager (SSM) was widely downloaded with more than 20,000 downloads, in addition to being packaged into the Fantastico web-hosting control panel tool. PhotoGal probably had around 5,000 downloads. For the commercial products, it’s much easier to gauge, because of sales figures. Affiliate Manager had a small user base, seeing use with a handful of clients. DLMan was more successful, at least in terms of revenue.

DLMan took about a week of development effort to build out for the first release and went on sale for $45/license + additional charges for installation and extension modules. If I was billing the development time at what was my standard consulting rate, the product would have roughly broken even. DLMan did drum up a steady business in related consulting, modifying the product to suit a variety of purposes and industries and this business certainly helped make the product worthwhile.

Certainly, in terms of users or sales, I didn’t have any blockbuster successes. Still, the process of developing the software, supporting it, and learning what users really needed was most important, though, and gave me a number of lessons that I have pulled from as my career has progressed.

At a high level, developing the software gave me a better understanding of what it takes to write a system from scratch and made me a better consultant with this ability to look at systems with a deeper perspective. Supporting the software also put me in touch with the people actually using the code and showed me a whole host of new considerations to take into account when building products, along with the value of actually speaking with customers. I also gained experience with pricing, discounts, sales, and numerous other important points. But perhaps most important was that I learned about what’s really critical in terms of releasing software.

 

Lesson Learned #1: Being Open

Being young and naïve, the products were all released under a fairly restrictive license that I wrote myself. I wanted to keep people downloading the software through my site and was unsure what opening the code up under a full OSI-compatible license would have meant.

This is something that I still see today. There is this instinct, that because you built something, you want to hold on to it and try to find some way to benefit from it.

In retrospect, the better road would have been the open source road. While I was concerned about keeping control of the code and limiting modifications, this was counterproductive to what I should have focused on – increasing adoption and getting the code into the hands of users – building a community around the products. As mentioned above, much of the revenue generated from these businesses was actually in the consulting work and customization of the initial products. Not only would this not have been affected, it probably would have increased, because adoption would most likely have increased from having a less-restrictive license. As a result, being open probably would have had given a nice benefit to the bottom line, in addition to being the right way to do business.

 

Lesson Learned #2: Keep Updating

Looking back, the markets that I got into were good choices and the products were well timed. SSM came out about 6 months before PerlDesk (one of the most popular helpdesk scripts at the time) and its integration with forum packages was something that distinguished the product (and drew a userbase). DLMan didn’t really have many competitors upon release, though a SaaS-based offering was released soon after (which was before many of the digital-download enabled shopping card packages).

After the fun of building a product was over, though, and having lots of new ideas, I was usually ready to move onto another project. I would still actively work with users needing help through the forums, but in terms of new releases, they were very rare. Other offerings coming into the market combined with sporadic updates to my software was not a good combination and led to a declining userbase.

 

Lesson Learned #3: Remaining Focused

Following SSM’s release, I kept looking at new competitors that were emerging and their larger feature sets. The one SSM competitor that was really noticed was PerlDesk (as mentioned above). I’m not quite sure of the exact cause, but PerlDesk got a lot of attention following its release and gained a big following. The feature set was roughly the same at the outset, but PerlDesk kept releasing and adding new features. There was a lot of temptation on my part to match their additions at first, but then the gap got quite large and I lost my inspiration for the project.

Rather than suffering from feature-envy, I probably should have gone the other direction and kept SSM as a streamlined, optimized helpdesk tool. One aspect of 37 Signals’ Getting Real methodology that really resounded with me was the focus on getting something useful out to the users and keeping the feature set lean. Most of the features competitors had were nice, but not essential. Creating an effective core product that worked really well, and then working as hard as I could to listen to customers, would have been far more effective than succumbing to trying to match competing products feature-for-feature.

 

Retrospectively, there were certainly many choices that I could have made differently which would have probably resulted in a more effective product strategy and increased adoption/success. Still, the work certainly proved its value in terms of building my core consulting business and also teaching me a lot about critical success factors for software products. My overall product strategy was decent, at least in terms of market timing, since I found real need in markets that heated up soon after I entered them. But the most valuable thing I got out of the experience was learning how to take a product from concept to functioning software, satisfy customer needs, and what worked/didn’t work in terms of making that product successful. For that, the experience was highly useful and I’m glad that I had the courage and foresight at the time to take advantage of it as much as I did.

posts — 2 Comments
26
Apr 10

Three Decisions Every Founder Needs to Nail for Success

My recent post mentioned that I spoke to a class of aspiring high school entrepreneurs, via a program called Startup Afterschool, earlier this month. Phin Barnes, Principal at First Round Capital, also spoke to the students to give them a perspective on his experience as an entrepreneur and now on the other side of the table as an investor.

Phin talked about a number of topics, including what it was like to be one of the early employees at AND1 and how his video game startup, responDESIGN, was able to do a deal with McDonalds. One of his comments really stood out.

Phin talked about the founding of responDESIGN, the successes and challenges that they had, and the three decisions that every entrepreneur needs to get right to be successful. Those are:

  1. Team
  2. Idea
  3. Investors

That is, it’s really hard to be successful if you’re missing one of the key legs to the stool.

When you think about it, it’s really an elegant way of looking at things. Sure there are lots of other things that need to go well for a company to make the long transformation from concept to sustainable venture. However, if you don’t have these three things in place, that transformation is nearly impossible. Furthermore, once you have these three things in place, they’re also extremely difficult to change. The general idea is more or less locked in, though it will evolve. You can make changes to your team, but having too much instability among the founders and early employees is certainly not a good sign. As for investors, there’s no undo button for your funding deal.

So, the lesson was, choose wisely. Good words of wisdom. Thanks, Phin!

(I’d argue that advisors or mentors are really quite critical, too, as utilized correctly, they can keep you from stumbling into walls you didn’t see were there and they can help open doors that are otherwise shut to you. However, in Phin’s model, we can lump those into team – three key points sounds better than four. :) )

posts — 1 Comment
13
Apr 10

Invitations are a wall

Grungy WallI’ve stumbled across countless startups via Twitter, TechCrunch, etc. that sound interesting. I go to their site and find a beta wall requesting an invite code.

Like any good early adopter, I put in my email and close the browser window. A week or so later (sometimes much, much longer), when the founders get around to sending out the invitation, I get a fairly non-descript invitation from a strange company name in my inbox. All of the initial motivation that I had to check out the site is gone and more than likely, I’ve forgotten what this particular startup does (given that startup names are so random these days, due to domain availability…).

I realize that invitation walls are sometimes necessary, but when you finally do get around to sending out the invitation, please remind me who you are and why I should care (again)!

posts — No Comments
21
Feb 10

Best practices for applying to seed accelerators

A few weeks ago, I posted some advice to entrepreneurs applying to the various seed programs. As the deadlines loom, I’m sure that many more are in the process of tackling the application. I’ve been reviewing some applications for DreamIt Ventures and based on some of what I’m seeing in those reviewed thus far, I wanted to put some additional advice out there.

  1. Put some thought into the applications. The program coordinators aren’t expecting an essay for each response (in fact, it’s good to be succinct), but one sentence responses to questions that don’t demonstrate any effort, thought, and/or motivation are not going to help your cause. Motivation is big – not showing any in your application begs the question if you’ll have the energy and drive to push a startup through to success. Remember, this is an application for thousands of dollars and hours upon hours of mentoring. Inspire some confidence that you can take advantage of this and harness it to achieve what you proclaim. As an example: In response to the questions around competition, don’t just say something to the effect that “There is no competition. We are the only ones who have been smart enough to think of this idea.” First off, it’s a red flag that you don’t think there’s any competition – there’s usually always something you can point to. Second, even if there’s nothing you feel competes directly, use this as an opportunity to emphasize your competitive advantage. I focused on the competitive question because that’s one that stands out to me, but this is equally true of any question on the application. Take some time. Think. Don’t take the easy way out of a question. That’s the fastest way to get a rejection.

    2.  

  2. Co-founders and the product. Everyone who writes one of these advice posts talks about the quality of the team. Even though (in general) single founders are red flags, do not just add a co-founder because you need a second warm body. Make sure they add something to the overall package. And if both of you are business grads and have only studied marketing, let’s be realistic – how is the product going to get built? The product is an integral aspect of any startup, so you’d better make sure that your application shows evidence of how you’re going to be able to make something. Not having a dedicated technology co-founder, is a red flag, but if you’re thinking there’s some other way to implement your plans, you had better be extremely detailed in explaining your thinking. And when describing your tech co-founder’s experience in the application, this is when it’s important to illustrate relevant past work. Please don’t just toss in generic buzz words – people with tech backgrounds will see through you and discredit you. Demos, prototypes, mockups – any kind of code will help to demonstrate that there’s something to your team.

    3.  

  3. For the love of all that is good, don’t simply submit an application that is a blatant clone of one of the program’s earlier portfolio companies. First off, the partners have been advising this company for almost a year at this point. There’s a very good chance they know as much about the market as you – you’d better make sure you show that you’re an expert in the space. Any gaps in your thinking will be extremely evident. Second, you’d be well advised to show some original thought and differentiate yourself somewhat. It’s been nearly a year since the original company was accepted. The market landscape for startups shifts extremely rapidly. As such, logic bears that something must have changed or progressed. The original startup has learned and evolved. Does your idea show the same evolution? In general, I would be cautious about cloning ideas – I think there’s little reason to accept them and furthermore, if you’re showing the kind of forward thinking and innovation that these accelerator programs promote and encourage, then you’re probably not going to be an exact clone anyway. Iterate and evolve. You’ll be doing it all summer anyway.

Finally, I can’t overemphasize the importance of building a dialogue, as I wrote earlier. Don’t wait until the last minute! Allow time to have a conversation! But also, the strongest applicants find ways to go beyond the application form to show the program that they’re motivated and have what it takes to get stuff done.

← Older Entries
Newer Entries →