Yes, I am still alive…and still blogging…Just not here.

I have been focusing on keeping good cadence on our StrikeIron blog. Take a look at http://blog.strikeiron.com 

Steve Blank wrote a great blog post called “VC’s are Not Your Friends” that really struck home.

If you haven’t read it and founded, work, or are otherwise associated with a venture backed firm, read it. If you have read it, read it again. VC’s are not your friends, this is business.

If you are new to the world of venture backed companies, here is a quick primer: Venture Capital firms have to raise money too. The capital they invest comes from Limited Partners (LPs). LPs are typically pension funds, high wealth individuals, or other large investment funds that are looking to diversify their portfolio with a high risk, high reward investment class. The goal of a VC is to get a couple of homeruns and a couple of singles/doubles out of their fund during the typical 10 year lifespan. This generates great returns for their LPs (and themselves). Successes also give VCs the credibility they need to raise subsequent funds. Not all portfolio companies will make it though; it is part of the game.

It was almost exactly a year ago that we wound down my last company TapRoot because we were not able to raise our Series C.

It was the most disappointing moment of my career. It was exceptionally hard to let go an amazing team who worked tirelessly on our products. I felt like we let down our customers and partners who helped us define and refine our products and had faith in our team to deliver.

Even though our investors did not continue with a third round, they acted with class. They allocated severance which certainly helped in a down economy (the vast majority of the team quickly found other jobs). They didn’t make it a traumatic “lock the doors” type event. The team actually stuck around to help us make sure all the code was checked in so if we were able to sell the assets the acquirer would be able to pick up where we left off. They were a good group of engineers no doubt. Most of all, they made it clear it was a business, not personal decision. I would happy work with and recommend any of them again.

Startups are an exploration. Sometimes you find what you are looking for, other times it doesn’t work out. The most important part is to learn from the experience.

Take a look below for the top 5 things we did well, and the top 5 I would do different if I had the chance. 

In 2009 we started the development of a new mobile analytics product at TapRoot. During that time we also sold off most of our business to a company called Neusoft.

The goal was to move forward with a small core team and the Embedded Mobile Analytics product. We had our pilot customer, one of the largest mobile operators in the world, and the development effort was going well. Unfortunately we were not able to raise the capital needed to take the product to market.

That was about a year ago and I have reflected quite a bit to make sure I learn as much as I can from the situation.

Here are the top 5 things we did well and the top 5 things I would do differently:

What we did well:

1. We had a great team. I can’t say enough about them. There were no sales vs. marketing vs. product vs. development fighting. We worked together toward a common goal. Think flow.
2. Engaged early and often with key customers and partners. We were outside the building to help us understand the needs from a customer point of view. We learned a lot in a short amount of time.
3. Tying closely to #1, we had a great market development strategy. Our platform could be tailored to two very different segments. We did not have the resources to attack both. We got out of the building and talked to prospects in both markets. After these discussions, we had a good idea about which segment would lead to revenue quicker (coincidentally, it was not the segment we originally thought!).
4. We established partnerships that helped us get into customers we wouldn’t have been able to otherwise (mobile operators).
5. We landed a great pilot customer without “elephant hunting”. They were name brand but most importantly, they were a pleasure to work with, openly shared their insight and feedback, and were very optimistic. They wanted us to succeed.

 What I would have done differently

1. Although we were trying to find the minimum viable product, we could have gone lighter and gotten something to market quicker.
2. Focused on the analytics and data visualization earlier. There were reasons we avoided this but, in hindsight, it would have made the value of the product much easier to communicate.
3. Pushed our pilot customer for more financial commitment. This is one I am not sure on. The assumption was that we would get our Series C and the nominal financial commitment from our pilot customer was enough skin in the game but it may have helped if that was a bigger number.
4. Picked our handset platforms in a different order. A product strategy thing but I would have done it a little differently based on what I know now
5. Crowdsourcing. One of the other players in the field, RootMetrics, did a great job of generating some buzz and real world data with crowdsourcing.

Life is a constant education and each of the 10 items above (along with the lessons of every day since) will shape my career…I hope they are valuable to you too.

A few weeks ago, I went to the annual sales kickoffs in New Orleans for one of StrikeIron’s partners. It got me thinking about how to manage the multiple ‘sides’ of a business model, specifically in the context of a startup.

I consider a side of a business model any stakeholders, or set of stakeholders, you must actively manage to serve your customers and monetize your product or service.

For example, if you are an independent software vendor that sells directly to businesses (via inside sales, web sales, field sales, etc.) without any significant partnership development, this is a simple one sided sales model. However, if you are an embedded software vendor that sells to device manufacturers and you need relationships with chipset vendors to get early, developer access to their chipsets, this sales model would require two sides. Of these two sides (typically) only one, the customer, is monetizable.

There are a couple of reasons why this matters…

• More than 1 side requires more resources to manage. You now need sales resources to sell your product and business development resources to create the required ecosystem. You effectively have a hidden cost-to-serve.
• You lose control over your time-to-market. Each side you introduce means an extra stakeholder that may or may not share the same motivations and urgency as you. This adds risks to your sales cycle and ability to deliver to your customers.
• Credibility. The addition of an additional side may decrease or improve your credibility based on who the additional ecosystem partners are, what the barriers to engaging with them are, and how they treat (or are perceived to treat) their partners and customers.

Each extra side makes your business model more complex and potentially more risky. By the same token these extra sides may add credibility, barriers for your competition, and streamline the sales cycle.

So how can you manage the additional sides as you are developing and executing your business model?

• Are these additional complexities are necessary? Can you simplify your business model? What are the tradeoffs?
• Understand and communicate what’s in it for each side. What value are you adding to your partners? What will motivate them to dedicate the time and resources to support you?
• Hedge your bets. Can you take the product to market with a 1 sided model augmented with a more complex model in parallel or in the future?
• Balance the number of partners. Too many partners is dilutive and resource intensive. Too few and you may have bet on the wrong one(s).

Each business opportunity has different dynamics, internal and external, that will drive the number of sides required. That being said, it is important to think through your model, the complexities, and how that will impact your ability to build your business. Also, being thoughtful on these issues will help to avoid chasing ‘shiny objects’ as new partnerships opportunities come up. 

We recently closed a deal with one of the largest heathcare systems in the US. As we were going through the sales process, I started thinking about some of the challenges health care systems face in balancing their IT strategy (and their $73.1 Billion budget!) with strict government privacy regulations, especially in the context of adopting cloud based services.

In 1996, the Health Insurance Portability and Accountability Act (HIPAA) was passed. Part of HIPAA was to specify a set of rules around an individuals health care records and data called Protected Health Information (PHI). In 2009, the HITECH Act was passed to address the privacy and security of PHI (or ePHI when transmitted electronically).

Health care entities such as hospitals, clinics, etc. are responsible for the protection of ePHI. As such, when they engage with a third party vendor, they convey those responsibilities to the third party.

So what does this have to do with cloud computing? Well, if a could computing vendor is hosting the data, they need to regulate the security and accessibility of this information. Additionally the health care provider needs to make sure their vendor isn’t going to expose them to ePHI violations.

For a new(ish) paradigm like cloud computing, this trust may not yet be established. This ties right back to my prior post on dipping their toes back into the cloud with transient services. Leverage the new paradigm while minimizing ePHI violation risk…

Let me know your thoughts…

The paradigm of using public cloud based resources certainly raises red flags in the minds of many IT leaders. Their concerns make sense. Data is an asset that should be closely guarded to preserve its value. The diagram below represents the consensus from just one of the many IT surveys that highlight the perceived risk of cloud computing.

One of the ways to mitigate the risk and dip your toes in the cloud is to use a transient cloud service.

For example, at StrikeIron, we provide Data as a Service centered around data quality and customer communications. We have two components of our value propositions. First is around the actual service being offered, for example email verification, address validation, or SMS text alerts. Second is around our DaaS (Data as a Service) platform.

A cloud based DaaS platform means customers don’t need to buy servers, routers, OS’s, and software applications. They don’t need to apply patches, virus updates, and software updates. And most of all they don’t have to update the actual data source weekly or monthly. We do all of this work and our entire customer base can leverage the platform consuming the data at the time, place, and amount they want.

The cherry on the top for those companies that are still worried about using cloud based services. We are transient. You call us, we do the work, return the result, and your data isn’t stored…this means the risk associated with hosting your data on some outside-the-firewall system is eliminated.

For companies who are a little hesitant to move their highly proprietary enterprise systems, storage, CRM, etc., this provides a great way to start enjoying the benefits of the cloud without having to jump into the pool headfirst. 

One of the core components of the cloud computing ecosystem is the notion of ‘as a Service’ (or ‘aaS’). The ‘as a Service’ tag has migrated to several new uses.

Here is my attempt at a set of definitions (and please comment if you disagree)

• SaaS (Software as a Service) – I mainly see this as an application that runs in the cloud and requires the user to download no (or very little, maybe a browser plugin) to use the application. (e.g. SalesForce, Cisco WebEx, Google Apps)

• DaaS (Data as a Service)* – This is providing data over the cloud either as the result of a query (is the email address me@acme.com valid) or involving a data transformation (correct the address 101 First Ave, Mytown, NC 2513). (e.g. StrikeIron!)

• PaaS (Platform as a Service) - Providing a platform for running applications, data storage abstraction, etc. One step up the software stack then IaaS (e.g. Google App Engine, Force.com, and the newly wealthy Heroku team)

• IaaS (Infrastructure as a Service) – Providing a virtual machine and storage mechanisms that can be loaded with operating systems and software (custom, open source, commercial, etc).  (e.g. Rackspace, Amazon, GoGrid)

Clear as mud? There is certainly some overlap between the different technologies but at the end the trend is clear. Leverage the efficiencies of scale, lower the barrier of entry, and speed up the time for implementation. 

*DaaS can also refer to “Desktop as a Service” and “Database as a Service” in several sources. 

I have to admit, I am a little sad about missing the upcoming wireless/consumer electronics tradeshow season. No Vegas, Barcelona, Orlando whirlwind trips for me this year (although a partner sales conference in New Orleans in a few weeks helps to ease the pain) 

One of the most interesting announcements from CES is Vizio’s tablet and smartphone.

Vizio is only an 8 year old company with north of 2 Billion in revenue and just under 200 people. They have managed to establish, from scratch, in 7 years, a household brand in TV’s.

Now they are trying to move from a mainly a TV company into a true consumer electronics company. They have partnered with Google to provide the OS for the tablet, smartphone, and TV but the impressive part is they have created a common, entertainment centric platform across their portfolio called ‘VIA Plus’. 

Creating an differentiated identity in the smartphone space has become difficult…just ask Garmin, Dell, Sony Ericsson, and the list goes on. Even Motorola’s Blur social UI went from flagship to feature…but, based on the early reviews, it sounds like Vizio may have a shot.

Of course, getting operators on board for the smartphone is always a challenge, it will be interesting to see how they do for launch operators this summer. 

Now that I am wrapping up my first 6 months at cloud computing startup StrikeIron, I thought it would be a great time to start a Tumblr blog.

I am going to focus on a combination of the Cloud/DaaS (Data as a Service)/SaaS/IaaS market, wireless/smartphones/etc, and whatever other technology topics sound relevant and interesting. I am going to try to post at least weekly.

For my first entry, I would like to provide a quick, potentially self promoting, introduction. I joined StrikeIron in June 2010 as VP of Product Marketing. Previously, I had spent most of my 13 year career in the cellular handset / smartphone industry. If you are interested in my background, take a look at my Linkedin profile at http://www.linkedin.com/in/jhelmig . The StrikeIron opportunity was very attractive for a few reasons:

• The cloud just makes sense. At my last startup, TapRoot, we used Rackspace’s cloud (IaaS) to scale for customer trials and demos of our analytics solution. It was perfect, we didn’t have to buy servers or software, upgrade our Internet pipe, worry about security, and lots of other things. It was also extremely cost affective. I drank the cloud Kool-aid!

• Data quality is a huge and quantifiable problem. Money is wasted poor decisions are made with poor data.We had an MBA intern put together an ROI calculator for our customers and the payback was amazing.

• Growth is fun. The growth opportunity at StrikeIron is exceptional. If we listen to our customers and pivot just right, we can build a great company.

Future entries should be more interesting and exciting but hopefully this sets the context.