Image by vns2009 via Flickr
After talking to a number of entrepreneurs over the years, the vast majority are focused on a building a technology product (e.g. a SaaS product or web site). Of course, there’s a natural bias since that’s what I focus on but nonetheless I talk to very few entrepreneurs trying to build technology-enabled business services startups. A technology-enabled business service is a business services company that uses proprietary technology to deliver something better/faster/cheaper than if you do it yourself or hire a traditional firm.
Here are a few examples:
- SecureWorks – an Atlanta-based managed security services provider that offers outsourced solutions to monitor and test for different security issues (as was recently acquired by Dell for a rumored $650 million)
- Liazon – a health care and benefits broker (e.g. you can buy your company health insurance through them) that differentiates itself with a proprietary portal that makes it easy for your startup employees to choose from a variety of plans and allocate a set budget (instead of having a single health insurance plan for all employees you can have several and let them pick and choose)
- SoftLayer – data center and hosting services that differentiates itself through a proprietary portal, provisioning process, and APIs that allow it to offer dedicated boxes provisioned much faster than most providers
- WebGreeter – an outsourced live chat service for web sites where the call center agents are provided a simple list of questions they can answer otherwise they collect the visitor’s information for follow-up by one of your own employees
Each of these examples is a successful business with proprietary technology that give it an edge in their market. My recommendation is for entrepreneurs to consider technology-enabled business services in addition to technology products.
What else? What are some other examples of successful technology-enabled business services?
One aspect of product management that took me many years to appreciate is the potential support burden of new features. When developing a new product, even in the first 12 – 24 months, it’s so easy and quick to implement additional functionality there’s a tendency to add new features without regard to longer term implications. The most important aspect of product management is to be opinionated about what goes in, and doesn’t go in, the product.
Here are a few tips when considering the support burden of new features:
- Pay particular attention to anything that allows custom code like HTML, CSS, or scripting as these are challenging to support
- Watch for difficult user experience interactions like multi-select conventions
- If you find strong contention internally for how a feature should be implemented it could be equally challenging for users to use regardless of how it’s done
- Consider if the feature should be part of a specific plan or offering (e.g. more expensive plan or add-on due to the complexity)
Implementing new features should not be done in a vacuum even if you are opinionated about the product. In addition to curating the product’s functionality, the complexity and support burden should also be considered.
What else? What other tips do you have when considering the support burden of new features?
Image via Wikipedia
When people come to our office their first comment is always about the great views from the 34th floor on the edge of North Buckhead. Their second comment is almost always about the large LCD scoreboard we have in the lobby. People aren’t used to seeing a company’s current results(including revenues) and goals for the quarter prominently displayed for everyone to see. The LCD scoreboard sets the tone: results matter and we’re transparent about our progress.
Here are some benefits of the LCD scoreboard setting the tone:
- Everyone knows exactly where we stand on a daily basis via the LCD scoreboard in the lobby and the same Google Spreadsheet on the homepage of our intranet
- We believe in transparency and accountability the moment you walk in the door
- When things are going well, or not well, peer congratulations or peer pressure reinforce that everyone’s in it together
The LCD scoreboard seemed like overkill when we first did it because of the cost and effort but I can confidently say it was easily worth it.
What else? What are your thoughts on using tools like an LCD scoreboard to set the tone?
Image via Wikipedia
In the past two days I talked to three first-time entrepreneurs that wanted input on their ideas. Every single one cited the desire to use focus groups to help validate their project. Entrepreneurs don’t need focus groups. Henry Ford has a famous quote that exemplifies how I feel about focus groups: If I’d asked customers what they wanted, they would have said “a faster horse.”
Now, talking to customers and potential prospects is the right idea. Doing focus groups in the traditional sense is overkill and too expensive. Entrepreneurs are much better off seeking out prospective customers and engaging in a customer driven process using the 4 Steps to the Epiphany (free PDF of book) or Lean Startup model.
A few things to consider when attempting to validate a startup idea:
- Talk to at least 10 potential customers about the idea and get their input
- For the prospects that express interest, ask for a firm commitment for them to use it (e.g. timeframe, cost, etc)
- Ask them how they go about solving the problem now as well as what other things they’ve looked into to solve the problem
- Seek out entrepreneurs or potential advisers that have relevant domain expertise
Validating an idea before jumping into it full-time is one of the harder things to do as an entrepreneur. My recommendation is to roll up your sleeves and talk one-on-one with as many people as makes sense and get direct feedback.
What else? What other tactics do you have to validate a startup idea?
Image via Wikipedia
Late this afternoon I had a call with an entrepreneur that I’d helped in the past. He’s working on a new idea and wanted to get feedback. Yesterday he sent over some slides about the concept and I skimmed through them. After the usual first five minutes of a phone call I quickly asked for to hear the short pitch on the new venture. Unfortunately, he talked for five minutes straight and it still wasn’t clear. I then asked again for him to restate the idea in less than 20 words and he didn’t have any luck.
Startup founders need to provide a concise explanation of their idea. Here are some questions to think through:
- What’s the offline analogy?
- Who has the pain?
- How is it accomplished now?
- How would you explain it in under 20 words?
- What’s the explanation for someone who’s in the industry (e.g. include the jargon)?
- What’s the explanation for someone random on the street (e.g. exclude the jargon)?
A concise explanation of a startup idea is hard at first but becomes easy with practice and refinement. All entrepreneurs need to have it ready at short notice.
What else? What are some other tips or questions for developing a concise explanation of the startup idea?
Image via Wikipedia
One of the nice problems to have as a startup grows is scaling the web app. Scaling the web app encompasses not only the back-end infrastructure but also the user interface components as well. We like to take the approach of providing oxygen (client usage) to the new features and improvements as quickly as possible and iterate from there, resulting in scaling rework once the need arises.
Here are a few tips to keep in mind when scaling a web app on the front-end and back-end:
- Consider caching the values of any SQL COUNT() calls as new columns in the database updated asynchronously on a schedule (we’ve encountered this many times resulting in performance hits until they are corrected)
- Be wary of database-level full-text searching or advanced searches of structured information as specialized indexers like Sphinx and Lucene are much better suited
- Any user interaction that takes more than five seconds should put in a background job that triggers a message to the user when complete
- Consider the user experience when something like a drop down or chooser has a large number of fields (e.g. once a drop down has more than 15 choices have it change to a type-ahead selector or some other input type)
- Implement an aggressive archiving plan early of for any data that isn’t critical and can accumulate over time as it is harder to take things away later as opposed to providing more (e.g. how much time certain data is available before it is purged)
These are just a few of the items to be cognizant of when scaling the front and back-end of a web app.
What else? What are some other tips for scaling?
Image via Wikipedia
Early today I headed downtown for jury duty. In Atlanta it seems that you get called to jury duty every 18 months, or at least I do. The good news is that, like today, I sat around for several hours (five to be exact) and was quite productive due to the limited Internet access. As expected, I came prepared with a fully charged iPhone, iPad (v1 as my v2 is on its way), and MacBook Air (v2).
Here are a few tips for jury duty from my limited experience:
- The summons says to be there by 8am but with such a massive number of jurors (Atlanta’s size, crime rate, or both?) things don’t really start until 9:30am as that’s how long it takes everyone to get in due to metal detectors and individual check-ins. I made it in and was seated by 7:55am but I could have gotten there an hour later and would have been fine.
- Power outlets are at a premium so bring a surge protector if you don’t have a great battery (or two).
- There is limited (read slow and spotty) free WiFi with username “guest” and password “guest”.
- Not really a tip but a judge came and talked to the 300+ jurors for 15 minutes and said that the most beneficial part of having the jurors ready and in-person was that when criminals get to their day of reckoning and know they are guilty, they often enter in a plea bargain in order to avoid making things worse in front of a jury. Basically, knowing that a jury is in the building and ready to go expedites many cases.
Thinking back to this morning it really was super productive. In a giant room with hundreds of people, no friends, no windows, and nearly no Internet makes for a conducive working environment, especially when you’re required to be there by law.
Yesterday Fortune magazine republished their 1986 cover story on Bill Gates and the Microsoft IPO. The article, titled Inside The Deal That Made Bill Gates $350,000,000, does a great job covering the spirit and nuances about Bill Gates and Microsoft leading up to going public on NASDAQ. Here are a few notes from the article:
- Bill Gates owned 45% of Microsoft after the IPO and was only 30 years old
- Bill Gates had an informal rule that employees could sell no more than 10% of their holdings after the IPO
- A price to earnings ratio of 10 at the time in 1986 was expected and was between what personal software companies and mainframe companies were trading at (now Microsoft trades at a 10.9 P/E ratio)
- Oracle went public a few days before Microsoft (now Oracle trades at a 23.8 P/E ratio)
- The stock started at $21/share and ended the day at $31.25
The articles touches on many more of the human elements of the IPO process including emotions, debates, and anecdotes. It is a great read for anyone interested in how an IPO works, technology history, and Microsoft.
Image via Wikipedia
More and more startups are instituting a policy to have newly hired software developers push a piece of code (feature or bug fix), albeit small, to the product’s production servers on their first day. The idea is that with web-based apps and software-as-a-service programs the act of making an update should be a simple process unlike the days of shipping a new product release once every year or two on disk hoping that everything was perfect (which never happened). Here are some benefits of having new engineers push code to production on day one:
- Sets the tone for a fast release process (potentially many times a day with continuous deployment), which often results in greater developer satisfaction due to receiving input from users as fast as possible (developers love to get positive feedback on a regular basis)
- Reiterates the fact that smaller changes lead to smaller issues and bigger changes lead to bigger issues (bite size chunks are best)
- Provides a sense of satisfaction to the software developer on their first day that, yes, they will make an impact
- Makes the process of write coding and seeing it live the product no longer daunting
My recommendation is to consider having new developers push code to the production servers on their first day on the job.
What else? What other benefits are there of pushing code to production the first day on the job?
Image via Wikipedia
A few days ago I was talking to an angel investor about his experiences. From a previous conversation I knew he had a nice exit four or five years ago so I asked what he learned from his experience in that deal. After he shared some takeaways I casually asked when he first invested. His answer shocked me: from the time of first investment to selling the company it took 18 years. There’s been talk for a couple years now of exits taking longer and that angels should expect deals to take 7-10 years for an exit. 18 years for an exit seems like an eternity.
Some interesting notes on the 18 year angel investment:
- The angel investor invested in the company three times over the first five years
- The company had several small pivots before finding a market opportunity
- The company was close to running out of money when the founder died and the company had a $1 million life insurance policy which provided it capital to keep going
- A new management team was brought in and was able to make the company successful by signing distribution deals with several large companies
His stories drove home the fact that things take longer than expected and a good bit of unplanned events are part of the journey.
What else? What other stories have you heard about angel investments taking a long time?