Posted: May 7th, 2010 | Author: Robert Shedd | Filed under: posts | Tags: best practices, business, consulting, shedd technologies international, software, technology, thoughts | 1 Comment »
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”¦
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.
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.
Posted: April 26th, 2010 | Author: Robert Shedd | Filed under: posts | Tags: best practices, entrepreneurship, startups | 2 Comments »
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:
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. )
Posted: April 13th, 2010 | Author: Robert Shedd | Filed under: posts | Tags: best practices, social media, startups | 1 Comment »
I’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)!
Posted: February 21st, 2010 | Author: Robert Shedd | Filed under: posts | Tags: best practices, dreamit ventures, seed stage accelerator programs, techstars, thoughts, y combinator | No Comments »
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.
- 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.
- 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.
- 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.
Posted: February 18th, 2010 | Author: Robert Shedd | Filed under: posts | Tags: best practices, entrepreneurship, startups, thoughts | 1 Comment »
I enjoy speaking to aspiring entrepreneurs. Earlier this month, I spoke to a class of seniors at Drexel University about early-stage startups and entrepreneurship. This is the first post of a couple on some of the topics covered.
I’ve found that students are usually intrigued by startups. They like the idea of working for a small, dynamic company and being able to make an impact rather than lost in a corporate machine. That said, many students are intimidated by the process of starting a business and would rather join a startup that’s already up and running. This in of itself isn’t always the easiest thing. Startups have limited time and money to spend on recruiting. You’re most likely not going to find them at the career fair table next to the Fortune 500 guys. So, how do you get a position with an early-stage startup? Here are some tricks…
There are a lot of people who talk about why social media is important. And there are a lot of people who give you weird looks when you tell them that you’re on Twitter. Ignore the latter.
Here’s my personal experience using social media with startups: I’m working for Three Screen Games because of LinkedIn. I was already connected to my co-founder via LinkedIn ““ we met at Penn State, kicked some ideas around while we were there, but didn’t end up working together then. But, when he decided to leave his former position, he updated his LinkedIn status, which showed up on the dashboard or in the weekly email alert. I was curious (his previous venture was going well), so I sent him an email to see what he was up to ““ he didn’t give me a lot of details at first, but we started exchanging a couple of emails, and sure enough, it soon made sense for us to talk about working together.
Resumes are so passive (Andrew Hyde just published a great post about this). Whereas, LinkedIn, Twitter, and blogs allow you to build a presence ““ a brand for yourself ““ and engage with people that you’re interested in networking with. They allow you to take charge of your networking.
Hopefully, the startup that you’re interested in makes something that you like. (In fact, if it doesn’t, you should find something else!) Say you’re interested in working for FanGamb, for example…
What’s the easiest way of getting involved? Show us you really, really care. First off, use the product. Actively use it, see what works well and what doesn’t. Then, get in touch with us. Give us your suggestions. But don’t just send us a quick email that says “hey, you should add this” ““ those emails get filed. Instead, engage with us ““ make us stop and say, wow. Show us that you’ve thought this through, that you’ve considered the angles.
Then, have a plan for how you can add value to the team. We’re busy, we’re trying to make progress one day at a time, putting out fires as we go. We’re not always stopping to think ““ “hey, we could really use someone to do X.” If you come to us, have shown us that you’re really into what we’re building, and then stop us and give us a great example of how we could operate so much more efficiently with you as part of the team, 9 times of out 10, that’s going to work for most entrepreneurs.
(And that’s true of most companies, too ““ showing the value that you can deliver works in the corporate world ““ but it’s usually harder to connect to the right people.)
Charlie O’Donnell , who works for First Round Capital in NYC, has an awesome post about this topic.
If you’re looking to get involved with a startup in Philadelphia, do you know about Philly Startup Leaders? In Boulder, the Boulder New Tech Meetup? In New York, the NYC Tech Meetup?
Startups are sometimes lonely. It’s usually just a few folks sitting in an office, working really hard. There are also lots of questions that entrepreneurs may not know the answers to. What do they do? They engage the local community. In Philly, it may be a little hard to see from the outside looking in, but the city has a great community for startups. As do many cities these days. The monthly meetups and get-togethers are a great venue to meet entrepreneurs and entrepreneur hopefuls that you might be able to work with.
Plus, each of these groups has an active mailing list. There are always startups looking for help, asking questions, and giving advice on the mailing list. It’s another great way to engage the community and participate. If you apply some of the principals discussed above, around personal branding and engaging with entrepreneurs about ideas for their business, I guarantee you, you’ll be making valuable connections and talking to entrepreneurs about problems that actually matter to their business in no time.
So, there are some thoughts on ways to engage early-stage startups and get involved. Feel free to reach out if you have specific questions or comments. It’s a fun topic and I’m happy to give you my thoughts.
Posted: February 8th, 2010 | Author: Robert Shedd | Filed under: posts | Tags: best practices, management, startups, thoughts | 2 Comments »
After the Super Bowl, CBS aired the premier of its new reality show, Undercover Boss. While I’m not usually a fan of most reality TV, I actually found the show to be interesting and worth a watch. While its merits as good reality TV may be debated, the show’s concept is one that all managers should stop and pay attention to.
I think it’s fairly common for those being managed to think that their corporate overlords don’t understand what they do, how hard they work, and in general, feel under-appreciated. It certainly doesn’t necessitate that a company have 45,000 employees (as Waste Management does, the company in the first episode) to find a couple of steps in a chain between policies being set at a company-level and workers implementing those policies. And the more steps you have, the more of a disconnect you get. Just ask any elementary school kid playing whisper down the lane.
Why don’t more corporate executives and managers try to step into their employees shoes every so often, to see how their policies are actually being implemented? Why is this a novelty fit for reality TV? Shouldn’t this be good management practice, that we see all the time from executives? Especially in a world where executives are trying to determine which jobs aren’t important any longer and should be on the chopping block?
In the corporate world, the practice seems to be for policies to be set, then communicated down the series of managers and their underlings via all-hands blast emails and quarterly conference calls. Sure, your direct manager might have a decent understanding of how hard you’re working and what resources are needed to increase performance. But, the farther up the chain you go, the more quickly individuals just get rolled up as metrics in a spreadsheet. Looking at a spreadsheet with your employees as numbers quickly makes you lose perspective on what those numbers actually mean in human-terms.
If more executives took some time to come out of the corner office and actually work with their employees in their jobs, they’d learn a lot more about how to set effective policies. It wouldn’t even have to be undercover management style – just watch the show to see what an impact it makes for your employees seeing that an executive cares enough to come out and see what they’re doing and how hard they’re working to contribute to the company’s success.
Startups don’t have to worry about this (as much) at the beginning. Everyone is usually in the same room. There’s only one level separating the executives from the worker-bees (not that anyone uses those terms). It’s very easy to see when a policy doesn’t work out, and everyone usually shares roles.
But startups (hopefully) grow, and grow quickly! This has the “executives” learning on the job how to manage people in the larger company. And then you need to start worrying about how to retain folks, that your company is a company people want to work at, and make sure that everyone shares the vision. How do you do that? We haven’t gotten there, yet, but I suspect that making sure you understand what your employees are doing (again, not necessarily “undercover management” style) will be a good start and an important way to make sure that you’re not setting policies that have employees thinking “that guy in the corner office has no idea what I do all day…”
Hm. Maybe there is something we can learn from reality TV after all?