Doing too much is a sure sign you don’t know what one thing to do. This one’s a tough lesson for entrepreneurs, and even when you know it, tougher yet to follow.
Archive for April, 2007
I was wrong. It hasn’t been the first time, it won’t be the last. It wasn’t purposeful, it was more like naivety, and only for having seeing it done right do I have the perspective to look back and call out the errors.
The focus on quality as priority #1 here at Ping has opened my eyes. In 15 years of software entrepreneurialism, I’ve always been one to fight for the new features, sometimes, sacrificing quality to do so. I was wrong. Let me tell you why.
It all boils down to cause & effect. If you knowingly sacrifice quality, the ripple effects, and down-stream costs will start to add up, and ultimately, they will start a downward spiral that’s very difficult to turn around. You will become so engrossed in making up for the job you should have done in the first place, that you won’t be able to move forward effectively. You will become paralyzed by the consequences of your prior decisions. First, you’ll notice that your support costs will start to rise. Soon, it will start to spill over into engineering, as the backlog of bug-fixes start to consume the bulk of your future feature agenda. Morale and confidence will start to be impacted, as customers take out their frustrations first on support and customer care, but over time, management as well. The time and energy that will ultimately be wasted, in the end, far outweighs any benefits you might have garnered by trying to stretch beyond your means by doing more than was possible without sacrificing quality.
I hear about the pain this poor decision making creates all the time now that my eyes are opened to this cause/effect. Typically, the people suffering from bad decision making are so inundated with problems pulling them down, they can’t see past their own symptoms, and thus, have no idea in fact what the root cause of their issues are.
There are always exceptions to every rule, and there have been many examples of very (temporarily) successful companies built on the backs of unhappy customers and poor products, but by and large, they are the exception. Build great, quality products, most the rest will take care of itself. Customers are more accommodating of a feature you don’t yet support than you’d think. Many times, you just need to ask if it’s ok to deliver that feature in the next release.
I sat in a presentation yesterday at SaaScon where Google described their vision for enterprise collaboration. I must admit it was compelling.while their ‘office’ suite will take a long time to catch up, the entire notion that email, calendar and instant messaging can be outsourced to Google does make a lot of sense. It eliminates the need for servers, backups, SANs, spam filters and lots of IT.
Their entire Google Apps offering connects and integrates with business via SAML.
Google Alerts pointed me to an interesting post over the weekend but the link appears to have taken me to a scrape of someones blog, and not the blog itself, so I’m at a loss to give due credit.
Someone named Jim was commenting on how convoluted the identity landscape has (or is about to) become. I’m reminded that the Elegant Solution is one in which you can no longer remove things (as versus add things). In the case of identity however, I suspect the market’s chaotic process will invariably introduce more ingredients than are necessary, before we’re able to strip things back to their core. Between here and there, it’s likely going to be a “convoluted and confusing” ride indeed. The below reminds me of a slide Doc Searls gave at one of the early Digital ID World closings. I’ll have to dig that up and post it here.
hyper-heterogeneity we throw into the IdM mix, the more convoluted and confusing
and treacherous it all feels from the user’s viewpoint.
IdM metasystem heterogeneity introduces odd geography into
the mutuality equation, threatening to turn what should be direct interaction
paths (i.e., logins) into indirect odysseys involving card-cluttered
conversations, eerie URI-infused interactions, insistent assertion insertions,
and restive roundabout REST-y redirect ricochets among too many moving
I cobbled together a working
IdM metasystem taxonomy that includes (in no particular order) myriad use cases,
interaction patterns, standards, identifiers, attributes, cards, card selectors,
credentials, protocols, authentication contexts, federation topologies, domains,
identity agents, directories, IdPs, authentication authorities, attribute
authorities, attribute brokers, certificate authorities, validation authorities,
in-person proofing agents, discovery services, RP/SPs, TTPs, PKI trust paths,
etc. (hmmm.I sort of broke my promise not to go exhaustive – pardon me).
How can parties rely, users prove reliable, and
mutual relationships emerge and remain durable in a cosmically vast, comically
dynamic, and freakishly fragmented crucible such as this?
It’s smart to not be too smart.
I’m a big fan of The Elegant Solution and Intelligent Reaction. In my experience, being too smart leads to an over-reliance on ones ability to predict the future, to the exclusion of life’s experiences and the wisdom that comes along with it. Being too smart is really dangerous.
There is no equivalent Newton Law of Motion for business, and thus, predicting the outcome of a complex set of intertwined events is not science. I’m a biology major, so it’s no surprise I find parallels in the life of business. Where I believe smart is best applied is in immediate problem solving and in setting a basic direction. Everything else is better addressed as an intelligent set of reactive moves, learning, adopting and adjusting to the circumstances and inevitable curve balls life throws your way.
Capitalizing on this in business requires however more than simply awareness. There is in fact both a culture and a set of processes that can help you keep the cement from drying on your business. In software, agile development is one of those methodologies, because agile predicts change, and defines its processes around maximizing efficiency in the face of change.
Or maybe this is all just a way of consoling myself as I get old, my memory fades, and I basically realize I’m not that smart.
What’s that old adage — it’s better to be lucky than smart?
I forwarded the “Time Rich & Time Poor” link to my management team this morning, and received back this email from our head of engineering, Bill Wood. It was simply too good to pass up posting.
“We build products for the time poor. By focusing on simplicity in every regard (installation, integration, administration), we effectively reduce the hidden costs of integration, as might occur with either open
source or larger, more complex suite solutions.
We move the budget focus from an operational cost (often a hidden or
confused picture as to where the money is going) to a capital cost that is visible,
has a low operational drag — so the client gets a solid cost to value
I’ve always felt that
management as whole really has little appreciation for the hidden costs behind
integration of vendor’s products. A product that is cheap to license, but requires a
great deal of integration engineering is really not
cheap. Expensive AND complex products double the hit. The diagram below illustrates this point:
on how a company is run and organized, some managers may not have to
justify their staff but instead are required to jump through hoops to
get purchases made. These sorts of companies may drift towards solutions
that on the surface, appear cheap. While not always the case, there are
situations where open source leads to this situation.
organizations tend to put justification along both axis and measure
themselves to the time it take to get things going, thus capturing the
true cost of any particular decision.”
Networks eat from the most recent, outer most layer in, and from the simplest concept out.
Just about the only thing you can’t reverse is death and the two seconds that just went by reading this sentence.
In the software business, time is not your ally.
Every second that ticks by, erodes the value of the version of software you just released. Software, like radio active decay, has a half-life. Features that were once rare, highly saught after and expensive a year ago, couldn’t be given away today. It’s as if there’s some sort of Moore’s Law at work here that predicts, perhaps even dictates the rate of software value decay. What would you pay for a copy of DOS, or Windows 3.1, or Lotus 123 today? New features which are more efficient, open source, competitive products, more efficient delivery models all contribute to this phenominon.
So, if you’re in the software business, what can you do to stall the hands of time? How do you turn time from foe to ally?
Marketshare is the answer.
The net present value of your software business can be boiled down to your ability to influence, to some point on the time horizon, purchases of new releases of your software and support services. The best way to do that is to get more people using your software — today.
When new people are downloading and beginning to use your software every second of every day, you effectively make time your ally. Now, you have a more levered handle on the future, and an ability to begin to influence future purchases and revenue in ways you would not have had, if the alternative was, your software sat on your hard drive, onsold and unused.
Mike Donaldson turned me onto this great blog post by Jeremy Liew at Lightspeed Ventures about differentiating your audience or target market into the Time Rich or Time Poor. He describes the difference as follows:
Broadly speaking, there are two types of internet users, Time Rich. I’d
speculate that many of the readers of this blog fall into the Time Poor
category, but the vast majority of internet users fall into the Time Rich
category. If you’re starting a new internet company, its important to know who
your audience is, and to make sure that you don’t let your own experience and
that of other Time Poor people guide you wrong.
Time Poor people use the internet to get things done. They are very task
focused, and their favorite websites help them use their precious time more
efficiently. Great examples of websites built for the Time Poor include search engines, first gen comparison shopping engines (trying to find the lowest price as quickly as
possible), ecommerce and lead gen sites where the
purchase is more functional than emotional, and many of the “social news” websites that
filter the news for you.
If you’re building a website for the Time Poor, your focus should be to
minimize their time and pages on site. As a result, business models around e-commerce, CPC and lead generation are good matches for
these sort of site – it aligns both user and site around getting to a
transaction as quicly as possible. Depending on what you do, you may even be able to
charge a subscription as well. Time poor people typically have more money than time.
Time Rich people use the internet to kill some time. They are bored. They are
willing to be diverted and entertained. Great examples of websites built for the
Time Rich include broad based social networks, targeted social networks, picture sharing sites,
related, anything sports related, social shopping sites (recreational shopping), social discovery websites that suggest new sites to
you, all video websites and causal games websites. Time rich people typically have more time than money.
At Ping Identity, we build software for the Time Poor. We focus on making our software achieve in hours what it takes weeks and months to do with competitive software. It’s all about speed and simplicity.
One of the dirty little secrets in enterprise software are the hidden costs of integration. It’s not uncommon for integration costs to be 3x, 4x or even 5x the cost of software licensing. Many companies underestimate these costs when they engage in a project, which is why so many projects run overbudget and are not completed on schedule.
I’ve only been involved in the security market for the past 6 years, and while I feel quite at home discussing the laws of networking, my internal compass for security is still finding North.
That said, I’ve observed certain characteristics about this market which are interesting.
First off, security really does appear to be an after-thought for most. This doesn’t mean that security architects aren’t doing their job. It means that they aren’t being given the time or budget to do things right the first time. It means that business units are primarily focused on increasing business and reducing cost (the bottom line), and only secondarily give any attention to what new risks are introduced as a result of the most recent set of activies.
Only when the new activity inevitably introduces new security vulnerabilities is IT given the funds to come back around and plug the holes. But by then, the only option is to put your finger in the damn, treat the symptoms so to speak, rather than resolve some of the root issues. It’s no wonder then that the options by this point are all tactical, point security solutions. I know this isn’t the case for all companies, but I think those companies are the exception, not the rule.
All this gets to the heart of whether or not companies view security as ‘strategic’ or ‘tactical’. For some, I’m sure that security is viewed as strategic competitive advantage, but for most, I believe security is important, but somehow always one step behind.
Perhaps this explains why those security vendors that specialize in what I call, wack-a-mole security solutions do so well. It’s because they’ve tailored their offerings to the inevitability that companies will continue to do things which expose new security vulnerabilities without the forethought and planning to resolve the issues at an infrastructural level beforehand.
What’s this got to do with identity? Well, for starters, investment in identity infrastructure is not an investment in wack-a-mole security. The benefits are far-reaching and foundational, but the understanding and investment often required in this sort of strategic forethought requires a commitment to the secure N-state that involves investment and planning, something many companies are not willing to do until the pain is staring them in the face.
Long live the wack-a-mole.