Visual Technologies: No Longer Optional

Each year, a small set of technologies graduate from academia and hackerdom to the real world. Most recently, chatbots, VR, 3d scanning, drones and visual object recognition have earned their mortarboards.

For investors, founders, technologists and artists it is critically important to keep tabs on what’s graduating and when optimally to begin experimenting with new technologies or novel approaches to old problems.

And therefore it is important to know where to look. Every day we are inundated with tech news, investor news, M&A news. But where do you go, online or IRL for clarity in where things are and where they are headed? In fact, the most inspiring people I know dedicate a material chunk of their attention to constantly honing their sources on inspiration and information. I try to do the same.

There are a handful of great meetups and conferences that achieve an elusive marriage of science, enterprise and pragmatic application. Finding them, participating in their communities and molding your learnings into tangible business and creative products is something I spend a fair amount of time on.

At my company, Kontor visual technologies are an essential part of the service we build for architects and designers. Our customers thrive on our constant improvements in image search and content presentation. We keep our eyes on what’s next in 3d modeling, VR, AR, image intelligence and many other areas. And to do that, we seek venues and networking opportunities to learn and share.

In 2016 I’d venture to say that no matter what you are building, visual technologies need to be part of your (ahem) vision. Immersive experiences must be part of any media offering. Visual intelligence must be part of any smart platform. Hardware and software businesses have to be current on what’s possible and what’s on the verge of possibility.

It’s my privilege to be involved again this year in the LDV Vision Summit, as I have been since its inception. Its founder, Evan Nisselson of LDV Capital, brings together startups, innovative big companies and a host of individuals who are driving visual technologies forward at a breakneck pace, all with a grounding in pragmatism and cooperative learning about what the near future holds. This event gets better every year; if you are reading this and able to get to NYC next week, you most certainly should attend. Join us and tell me about your predictions for the near future and what you are doing about them.

(cross-posted on Medium)

Roadmapping to Nowhere

(with Jennifer Gormley)

Product roadmap meetings — here’s the ideal: You and four other people cram into a small conference room that’s also stuffed with Post-it notes, whiteboards, and maybe even a slide deck. The scent of dry erase markers hangs in the air. It’s the fragrance of promise, a bouquet of hope. The idea is to come up with a plan for what the team is going to build in the next couple of quarters. A clean, prioritized list with strong consensus behind it. Ideas flow freely and fall into place like they were sent down from upon high.

Now, here’s the reality: You say, “We’ve got 37 great feature ideas to run through and plot out against our dev resources, user needs, and product vision. We need to explain to the board why we’re doing what we’re doing and stick to the plan. So I think the best way to…” and then everyone in the room interrupts you at the same time:

The Engineer: “Uhhh, yeah. We don’t really have any resources available with all these bugs the designers are flagging. Seriously, I can’t put it on a half pixel.”

The Designer: “If you’re going to tell me again we can’t do Feature 19 — that animated kitten gif for the users who get on the leaderboard — then I don’t really need to be here. And you all know I like blue, so make all the new features blue.”

The CFO: “He’s right. We don’t have any resources — since they are mostly playing
foosball in the lobby…”

The CEO: “Well, I’ve already sold Features 35, 36, 12, and eight to our new client in my last meeting with them, so those go to the top of the list…. And I have 2 more to add that their secretary’s cousin thought would be cool…. But of course we can do those after the four I just listed get finished in Q1. I can be reasonable.”

The onslaught draws a sigh out of you as you wonder if it is okay to drink at 10:17 am. As you uncap a marker and pass the sticky notes around, it’s clear that this effort failed before you all even squeezed into the room.


Product Design is fraught with best guesses, good ideas nestled among complex bad ones, and tenuous relationships with distant, sometimes theoretical users. Product roadmapping sessions are a strange mix of passion, interpersonal influence, poor planning, and misdirected energies. We’ve been in what must be hundreds of product meetings, and come up with one universal truth: Product Design = Hard. There’s no getting around that. Creating product roadmaps, however, well that can be easy. Seriously. Easy.

Recently, we faced the challenge of road mapping exactly 37 features with a new team. We didn’t want to make the same mistakes we had each made with previous teams, which almost always went like the example above. With this new team, we had just launched v1.0 of the product together. And remarkably, we all still liked each other. We even felt good about moving to the next phase; our product was in the market and feedback was coming in, mostly positive.

We looked at the blank sheet of paper upon where next year’s plan was about to unfold, and we thought: instead of tackling things the usual way, let’s take the personal passions out of it. Questions immediately clouded the way. This time, can we make — with a new, unsullied team — a less contentious, more productive, and more confident (team wide) roadmap? Could we filter out personal biases and focus only on goals (for our company, for our users, for our bottom line)? What basic math would result in a non-controversial, prioritized list to tackle with available resources? And could we use the list to make smart choices about spending more on developers, with quantifiable market impact?

Hell yeah, we could — and it actually works.

We considered 5 key perspectives:

  • Market Perception: Are we a leader? Do we have feature parity with others?
  • Cost Savings: Does the feature make things more efficient for internal ops? Solve technical debt that is becoming costly?
  • Key Vertical Differentiator: Does the feature clearly distinguish us among competitors?
  • End User UX Perception: How great is the UX for the bulk of our users?
  • Administrator UX Perception: How great is the UX for our purchase decision makers?

…and one overarching key driver:

  • Revenue Generation Potential: Obvs.

We began by asking the senior subject matter expert in relevant departments to rate each of the 37 features from the perspective of their team. These ratings were done based only on the title and brief description of the feature, because we didn’t want to spend a lot of time building specs or wireframes at this early stage. Ratings were done on a scale of 1–5 (with one being little to no potential impact, and five being high to “we better do it or else” potential impact). They did this in a vacuum. That is, no one knew how the others were rating things.

The benefit of this blind rating, done only in one’s area of focus, is that no one is influenced by the others’ numbers. Groupthink becomes negligible, and features which might otherwise overlap on a feature/value matrix begin to come into stark contrast with one another. When we reassembled to look at the features and their ratings as a group, it was clear something remarkable was happening. We’d cleared away all the extraneous debate and laid bare the priorities our collective brain deemed most critical to work on. Magic — or is it math?


Our Mathematics of Roadmapping:

For each feature we calculate a “Feature Score” (FS) as:

FS = (average of perspective scores) x (revenue generation score/5)

The first multiplier is a simple average of all the perspectives, each equally weighted. The second term overlays revenue on a normalized basis. By “normalize,” we mean we divide the revenue rating by the number of possible points so it’s value is never greater than 1. In this way, revenue can significantly boost or limit the FS but its impact doesn’t overshadow the average of the feature perspectives. Let’s take this for a spin.

Example:

  • Feature 1: “Improve User Registration” had an average score of 2.6 and a revenue score of 5, giving it a 2.6 FS
  • Feature 2: “Real-time Chat” had an average score of 1.2 and a revenue score of 1, giving it a 0.24 FS
  • Feature 3: “Offline Sync for Native Mobile Apps” had an average score of 2 and a revenue score of 3, giving it a 1.2 FS

By normalizing the revenue generation score (n/5) we can see the subtle variations in priority among all the features. Although the CTO wouldn’t have rated user registration improvements as a high-priority project, a balanced perspective shows it to be very important to take on. We have seen that natural patterns and affinities begin to emerge, like a focus on collaboration tool features, or on internal content authoring efficiencies. These roll up into easier market discussions, client pitches, and board reviews of the company vision.

This also works well when thinking about “themed” releases. If, for example, the next major market release has a “social” theme, the team can filter out features that don’t fit “social,” and then conduct the exercise. The result will be a prioritized set of projects that accomplish the theme.

Our approach has worked well for small teams, particularly so for startups. They tend to be constantly responding to changing priorities and moving targets, yet they need a roadmap to guide 3–6 months worth of development. For larger teams, it’s likely that more complex math, a different approach to averages, or laying in additional team perspectives would be more suitable. The inputs are not one-size-fits-all, but we think this technique is, and we urge you to try it. This alone isn’t a recipe for product success, but it might just save your team’s sanity, and get you a roadmap everyone believes in.

So, instead of the contentious clamor described earlier, imagine a quiet afternoon plugging in the data from your team. They provide accurate scores from their perspectives quickly and easily. You save hours avoiding the hair-pulling, passionate, but unproductive debates that devolve into eye-rolls over the designer’s animated cat gif. You come together to review the early plotting with a sense of order already on the table, making roadmapping actually easy.


When it comes to imagining and building great products, we wouldn’t trade the passion of startup teams for anything. And any tool or process that converts those strong feelings into a viable plan — or working code — is a great thing. So, in your next product roadmap session, give this math a chance. It takes the passion out of the planning and puts it where it belongs — into the work. Now stop sniffing those whiteboard markers and get to it.

Living Room UX, not SUX

The Web is abuzz this week with anticipation of the upcoming Apple Television rollout and how it’s going to revolutionize the way we interact with television programming from the couch.

While I agree that’s going to happen, I think the reasons are not as intuitive as the analysts believe. Apple isn’t going to do something we haven’t seen before, at least not yet. And, the living room TV content revolution has largely already happened.

Cable TV is a giant set of brotherly monopolies in the US. As Henry Blodgett points out, there is a history lesson to be taken from the fate of the newspaper industry. But that’s already an old story-  what the market wants is on-demand content with a great user experience (UX). It’s sad and infuriating that there is no competition in unified set top boxes or a way to accomplish delivery of all TV content. I’d pay for this, and so might you. For years innovation in television UX has taken a back seat to everything else in television while every other manner of consumer device has benefitted from faster hardware and smart interaction design. But how revolutionary can entrepreneurs be when the very core of the content ecosystem is locked? Just ask Boxee, Logitech, Roku and many others. Consumers have a binary choice: deal with crappy cable boxes or “cut the cord.”  More and more are cutting the cord. And getting everything they need from their screens.

So Apple can’t solve this. But- if they have partnered with cable providers as the swirling rumor mill supposes, Apple will be able to bring a decent user experience to television, in a way that the $99 Apple TV in my living room fails to do. Google failed at this marginally, too. Cable company set top boxes fail at it spectacularly.

One has to wonder who is responsible for cable box UX in OEM deals with Cablevision and Time Warner. Are they given shoddy second-hand hardware to work with? Terrible design teams? A mandate to frustrate their end users? Perhaps a crash quota of 2 kernel panics per week? Craziness, right? And yet, this is how much cable company television user interfaces suck.

If it takes the magical shimmer of Apple’s Television to break free, so be it. Apple doesn’t need to do more than provide a decent, modern touch-friendly experience to push the cable guys out of the UI business forever. But let’s hope and do our best to ensure that we don’t trade a bunch of regional monopolies for an international one. Give TV consumers a choice of great UX’s from which to choose, and I think they will continue to pay for cable subscriptions and suffer the advertising that makes the whole think tick. At least for a while.

Bring on great living room experiences powered by innovators who care about responsiveness, intuitive design, and have studied the art of user experience. Give me UX, not SUX.

PyCon 2012

I am excited to be in Santa Clara this week for company business and for PyCon 2012.

In recent years I have seen a tremendous lift in the size of the Python community and the innovation coming out of it, and I am thrilled to be a part of it. On Sunday I’m giving a “poster” presentation on this very topic; I’ll be engaging with the community here on why a Python-based stack is the right fit for our efforts at my new startup, Happify.

Beyond the obvious energy and creativity coming out of Python, my thesis is that NYC is becoming a center of great Python work in startups. Thanks to open-source frameworks like Brubeck.io, a growing talent pool of xooglers and Bay-area expats, and the sheer number of funded early-stage companies embracing Python (for it’s readability, productivity/fun, and good-enough performance), it is a natural and solid choice for NYC startup efforts. I am jazzed about becoming more involved with the NYC Python scene and contributing wherever I can.

If you are at PyCon, please say hi. I’ll post about my experience here when I am back in NYC.

Dusty

Looking back over the few posts on this dusty old blog, I’m amused and chagrined to see that I’ve mostly written about leaving old opportunities to pursue new ones. And here I am writing that post once again. But this year I’ll be writing more here.

I spent 2010/2011 building the technology platform and team at Bookish, and it was an amazing experience. But, for me it came to an end. I miss the team and the irreverent vision we shared, and the inspiration it brought me. As is always the case, ideas are cheap, money is out there and the hardest part is surrounding yourself with the right set of amazing collaborators.

Last year was busy.

  • We worked our butts off on Bookish.
  • I started the NYC SproutCore meetup and hosted several events.
  • I pursued speaking more aggressively, notably at MySQL Conf and Surge.
  • I was quoted in the WSJ and featured on GigOM with a headline that included the words “Harsh Mistress.”
  • I mentored at SeedCamp NYC and IBM SmartCamp.
  • I wrote a bunch of code outside of work and learned some new stacks and tools for the hell of it.
  • I got pretty excited about these wind synthesizer patches and wrote some music, soon to be released into the wild I think. I was quoted on the developer’s site.
  • I kept off the 15 pounds I lost in March.
  • I learned a LOT.

But there are a lot of things I didn’t do. I didn’t play or write enough music. And although I talked about it a lot and was on the scene, I didn’t found a company. Well, not until mid-December, so that doesn’t count.

So in 2012 I’ll do both those things, and write about my experiences here at least 12 times. I hope you’ll read and comment. Happy New Year!

Moving on to My Next Big Thing

I’ve started, edited, then deleted and started this post from scratch a few times now. Nothing clever worked. So, straight to the point. Three weeks ago, I moved on from 2 years of building a very awesome hyperlocal news aggregation platform at Outside.in to my Next Big Thing.

I’ve left to pursue a remarkable new opportunity that I can’t discuss quite yet; not because I don’t want to, but because, dammit, they won’t let me! It’s got some key facets that ultimately pulled me away from the killer team at OI: it’s in a space that will impact everyone I know, it challenges me to build apps that I will want to use every day, the scale will require some clever architecture that’s stretching my thinking, and it presents a true startup-business-building challenge for me. BTW, we’re hiring Scala and Ruby developers, so get in touch.

I am beyond proud of what we have accomplished at Outside.in, and of what the team I’m leaving continues to build there. The OI platform is in great shape. The public API is impressive and live and it’s one of the best out there, powering hyperlocal for huge sites like CNN.com. The next phases of its evolution are in the best possible hands. I’m incredibly thankful for the experiences of the past 2 years, and grateful to the team that made them possible.

ASSERT: Learn by Testing

My 6-year-old daughter received a microscope kit as a gift. It’s not the 50’s-style die-cast behemoth I had as a kid, with all it’s frustrating sample mounting and focus issues. No, this is 2009, and this perfect kids’ ‘scope requires no focusing and is small enough for her to wear as a necklace. And, it’s pink which makes the necklace prospect all the more attractive.

I’ve been teaching her a little bit about science and encouraging her questions. But really, I am passive, watching her formulate theories and test them. Our freezer is full of “samples” from the last Brooklyn snowfall.

She is learning to learn by testing, to come up with an assertion she believes to be correct, and then by observation rule it in or out. The application to programming and building systems is obvious, but easy to forget. I’ve sometimes fallen into the trap of assuming something is true, and relying on that assumption without a proper assertion and test. With the overwhelming amount of reading material available on what works and what doesn’t from “cloud computing” to scaling Ruby, from development environments to search algorithms, it’s easy to fall back on assumptions, most often and dangerously someone else’s assumptions. Watching my daughter’s inner scientist emerge has been a good reminder for me.

I now assert, and have proven, that even New York City snow is made of ice crystals and melts at room temperature.

OK, How to Start!

As a quick follow-up to the “How to Start Up” post, here is a pragmatic list of tools, tried and true via 2 recent projects of mine, and at least one more upcoming (which will also succeed ;)). The question I’m answering, of course, is: “what tools to use to bootstrap development on the cheap, and get yourself something launched with minimal headache and maximal features and reliability?” This is by no means a recipe for success or a religious treatise on how things must be done. It is a (hopefully) practical guide to what has worked for me in the context of real world “How to Start Up.” None of it substitutes for good engineering and smart entrepreneur-ing.

  • Linux: goes without saying. Oops, I’ve said it! I like deploying and developing on the same Linux distro, and for now that’s Ubuntu server. I find Aptitude to be the fastest, easiest package management system around. It does what it needs to and stays out of my way.
  • Rails: Yay, Ruby on Rails! Everyone loves it, right? It must be the shit! Well, feel free to join the pile-on. For a rapid, well-organized Web framework, it’s my choice right now, and I am a relative newcomer, still learning. I do love Ruby to get things done quickly and flexibly, and Rails is a natural extension.
  • Ruby: despite performance limitations, and single-threadedness for now, Ruby is the perfect “glue” code. If you need a server prototype or something asynchronous for your Web app, it’s a fine choice to start. For scripting and automating tasks, Ruby is right on. After all, that’s really what it was intended for.
  • Java: For any sort of real server heavy-lifting, Java and it’s infinite world of libraries and components are the obvious choice. All the complexity that you don’t need or want for rapid development of a Web app is much more palatable in this context because the benefits of performance, type-safety, threading, and dogmatic separation of concerns are well worth it. Lucene and Hadoop are great examples of very active projects with a lot of momentum, wide applicability, and lots and lots of good old Java. A requirement in my toolbelt.
  • Netbeans: I’ve done battle with IDE’s over the years. Even pitted one against the other. I’m fickle, easily distracted, and never satisfied when it comes to IDE’s. Right now I find Netbeans to be a clear choice for having struck the near-perfect balance between responsiveness, sophisticated editing, plugin-friendliness, and applicability for Ruby, Rails, and Java work. It generally stays out of the way but there is always something useful still to learn, and a zillion timesavers built by folks who understand what frustrates me!
  • Postgres: Another natural choice, given the Prototype Trap, and assuming you need a realtional DB. It’s very likely that you do, but not a given. PostgreSQL is proven to scale and cluster. Databases are quirky by definition, so putting your time into learning one that offers a lot of mileage is the name of the game. And, when you’ve got your funding you will have a relatively easy time finding a PostgreSQL DBA to hire for your team. Oh yes, and I love PGAdminIII, despite its unfortunately uninspired name.
  • Amazon EC2: I’m new to EC2, but pretty solidly behind it. At Digital Railroad I had the opportunity to speak with the EC2 folks and a number of competitors in varyinig degrees of depth. Remote virtualization is very clearly the way to deploy in the early stages, and depending on the application and resource needs may be right for the long haul. In the case of a current project, I was able to very quickly find a suitable base Ubuntu Server image, bring it up, and customize it appropriately. I’m a sucker for slick tools, and I must say this sucked me in further: ElasticFox.
  • 16bugs: Even if there are only 2 of you on the project, paper and todo.txt files will get old (and useless) quickly. Task and bug tracking are a must, and both are decently done and free at 16bugs.com. Don’t expect Bugzilla or JIRA-level workflow. Simplicity and just enough to do the job is what 16bugs is for, and it’s working well for our tiny team.
  • Yammer: This one is growing on me. While I don’t think Yammer is an essential tool, it does accomplish some things for small, geographically distributed teams. Things that aren’t obviated by project tools, IM, and email. My advice is to try it on a real project. As they say, your mileage may vary.

So there you have it. Not an exhaustive list, by any measure, but perhaps the means to get started on a lean, mean trajectory. It’s working for me.

How to Start Up

With the endless proclamations of the startup funding apocalypse inundating all our channels, it might be useful to consider how to start up a software thing and do it well on the cheap. I’m not talking about using the “cloud” or how you ought to look at open source… there’s plenty written about those and they pretty much fall into the “duh” category.

This is as good as any characterization of what we are facing. It’s not good. But there really is a lot of potential opportunity, heightened by the dearth of folks who can comfortably funnel some personal money into a project. Innovation marches on, and the gaps to fill with smart products, quickly developed, are accumulating at just about the normal rate. A project spun up with truly minimal cash and a real market, not a speculative one, will succeed if anything can in the next 12 to 24 months.

In the past couple of months, I have had the opportunity to advise and look at a number of Web/software technology ventures that meet these criteria, but are crippled, or doomed, because they just don’t know how to get started efficiently and set the stage for great things.  Here is some the advice I have given and thoughts that have come to mind of late.

  1. The Prototype Trap
    Beware of building a throwaway prototype, something that appears to work but really is nothing more than carefully propped-up demoware. In the good old days, such a diorama might have raised funds, but building it cost entrepreneurs money and served as nothing more than a starting point for spec’ing the real product. Don’t build a prototype; build an alpha, and define “alpha” in terms that accomplish your goals.  It’s infinitely better to choose platform(s), language(s), deployment environment, and base features than to build garbage demoware. The inital results won’t be as pretty as the polished garbage, but when you see something working, it’s really working. You’re team has identified real risks and pitfalls rather than emptily theorizing about real costs and unknowns.
  2. Hire/Partner with a Leader
    If you aren’t technical, or aren’t technical enough, hire someone who is. If you are human like me and need an invested collaborator, find that person as one of your primary efforts. Don’t accept that you tech lead has to be part of your outsourcer’s organization or that you, the most accomplished well-connected business professional that you are, can manage the risk yourself. Find a technical collaborator who grooves with your vision and working style. Offer equity for participation, hire a consultant who has a real interest in what you are doing and who will come aboard, or best of all spend on this full time hire, offer equity, and build a real partnership for execution. Spend more than 50% of you start-up time and energy identifying and exchanging ideas with this person. It is an obvious and critical investment that will yield staggeringly good returns.
  3. Start Microscopic
    Don’t bite off more than you can code! Sounds obvious, but it’s such a common mistake. If you start by identifying the bare minimum functional requirements to demonstrate your mission with real, working code you are comfortable handing over to alpha users and potential investors, and potential partners and staff and build nothing more… well, that’s really the start up app holy grail. Few achieve it, believe me. I think the tendency is to fail to find the perfect mix of focus and flexibility. If a project takes in the neighborhood of a month to implement, chances are very high that during that time the team will learn substantially more about the problem, the market, potential users, and competition that changes will happen. I’ve got some rules of thumb for this, and I will share them in a follow-up post. I know; you’d think this is common sense but I can assure you that very smart, savvy people with excellent ideas fall into all of the traps I’m writing about.
  4. Interest Alignment
    Regardless of who is building the alpha, make sure your respective interests are well-aligned. Your technical leader will push on topics such as framework choices, development environment, source control, and implementation time. Equally important is User Experience and performance, which will float or sink the idea in an instant on the monitor of your first alpha user! I like to set milestones that are small and very well-understood, and use them as checkpoints for Interest Alignment. Are the tools and framework choices holding up? What hackery has taken place to build this iteration, and is it something I want to inherit and support in beta and beyond? What code or approach was “borrowed” from another project? Are the resources still the best possible and invested, or are we slipping to the back burner? What User Ex compromises have taken place or are about to take place? These questions and more are relevant when implementation is done by outsourcees, contractors, and even new employees. And, one immutable fact is that if you are outsourcing, your outsourced team has fundamentally different interests than your own. The closest those interests align is in the goal of having your business survive. But, you need to do much more to lead the market and innovate, and they need you to survive and continue providing a steady flow of income.
  5. Alpha Wise and Beta Foolish
    Go into it assuming you are going to succeed, where success here is defined as moving from Alpha to Beta and eventual launch with real users and enough funding to do it all justice while not starving. Getting apps to market, and a large component of the art of development, is compromise. Finding the optimal trade-offs as goals change and timelines compress is not scientific, despite what a lot of books, brochures, and coursework purport! You often have much more wiggle room with the alpha time line than with subsequent ones. I always try to use this to advantage, insisting on building enough of a foundation to support what we imagine will subsequently sit atop it all. It’s very important not to shortchange your initial implementation and have the confidence to build solidly. There will be compromise, but don’t rush these decisions; a quicker-to-build, shaky alpha will always cost more to revisit as you are sprinting toward beta and launch than the cost of building solid and letting the foundation have some settle time in alpha.
  6. Outsourcing: The Glass is Half Full and Evaporation
    Assume the worst when you are outsourcing. There are many, many strategies for managing outsourced engagements, but the best is to assume, at the outset, a pessimistic disposition. If things fail in some way, you will be prepared to minimize and deal with the consequences. Competent outsourcing managers and teams expect this, and it has little to do with your confidence in them, or their ability to earn your trust. Since Interest Alignment is implicitly handicapped when outsourcing, both parties must make the most of it. Excuse this analogy, but you are a client, and they are the server. Code defensively! Extending the glass analogy, I like the term ‘Evaporation’ to describe what happens when that half-full glass sits around exposed to natural factors. Essentially, if you don’t put effort into ensuring a quality product via testing, frequent contact and brainstorming, and code inspection done in-house, you face Evaporation. Over time, that half-full glass get emptier, and emptier.
  7. Outsourcing: It’s Your Source Code
    Always have access to your source code and documentation. Ensure that code builds and works on your hardware and subject it to your high standards. Know the dependencies yourself, and ensure that dependency bloat doesn’t occur on your watch.  The unthinkable extreme case of source code kidnapping happens more often than most people realize.  But death by a thousand cuts can occur when your team is not vigilant about quality.  Your app will bleed to death from a zillion cut corners. Keep an eye on updates every day.  After all, this is why you hired or partnered up with a rockstar technical leader.
  8. Live with It!
    Well before real users assail your system, make sure you and your team understand all of the implications of running it. How many machines or could slices do you really need? Does the code recover from failure? Does it care? What registers as a catastrophic crap-out and waking someone up at 3 am, and who exactly gets that call? Rock sold stability is not expected in alpha, after all that’s why it’s alpha. But if you aim for better and achieve it, you will stand out. Live with the system you are deploying for a week before unleashing it. It will probably result in some work and living with an improved system for another week, but the time burned is another kind of important investment you will not possibly regret.

Starting things up isn’t easy or straightforward. But it ought to be fun, predictable, and inexpensive.

DRR and “What Happened?”

I am the former CTO of Digital Railroad, Inc. With the very difficult shutdown of DRR behind us, I’d like to set the record straight where I feel it is ethically OK to do so. Photo industry commentators, outside the fray and at times without a good understanding of what happens when a business is in distress, have attempted to lay out a time line and answer the elusive question, “what happened?” I’m writing this to correct some of the misinformation, and put forth clearly that the creators of Digital Railroad did everything possible to prevent the difficulty that our loyal customers are now enduring.

Among the things I cannot do are single out any individuals or companies, neither to praise nor criticize them, and please know that both praise and criticism are well warranted. I also cannot correct or clarify all of the misstated and erroneous information on various blogs, but I will make a few important points.

I hope that among the readers of this post are some of you with whom I had direct interaction through this difficult period. Each of you knows how the small DRR team that remained to the end (and beyond) fought hard to bring about a better resolution than was ultimately possible.

The most well-intentioned, objective explanation was posted by Allen Murabayashi of Photoshelter this week, and you can read it here. Allen was an insider to a degree because of his good work helping push for salvaging DRR photographer archives, which would have benefited our members and Photoshelter, both. As he reported in other posts, he also was in touch directly with investors and the DRR management team during this time. Nonetheless, his account gets some of it wrong. He writes:

“Portions of this document might be factually incorrect – I don’t vouch for the complete veracity, I’m just trying to shed some light on the situation, so that photographers can gain some understanding of the situation.”

True and honest. Thanks also, Allen, for not speculating on how DRR came to face financing challenges prior to the publishing of John Harrington’s post. DRR was a company with significant revenue and also significant investment. The economic downturn presented us with a time line for additional financing against which we could not deliver a solution. This despite strategic opportunities that never came to light publicly but were very much in play. Any of those opportunities would have resulted in a remarkable future for DRR and our members. But, they were not to be realized.

When Diablo Management was retained, it’s mission was not to liquidate the company, but rather to identify and accelerate any of a number of potential deals which would have preserved the business and the platform. Shutting down the company was called for only after the funds allocated to pursue potential deals ran out. Note that employees were not all let go simultaneously, and even some who were let go volunteered time to continue efforts to salvage the business, or minimally to export photographer and agency assets.

“Potential acquirers were asking questions, but there was no one at the company who had intimate knowledge of the business. Diablo tried to assemble answers, but they didn’t really know the entire situation.”

That’s not correct. I personally dealt directly with most of the folks asking questions, and with others indirectly. I am aware of every potential deal and did not turn my attention away from them until all were exhausted. During this time the team also made contact with a number of DRR members who had very difficult business situations to resolve, and these members were able to do so with the help of the staff who remained. I cannot sufficiently emphasize the fact that the dedicated team our membership came to know over the years went well above and beyond the call during DRR’s final days. Of course, I know this means little for those who have been dealing with major headaches as a result of what transpired.

Finally, Photoshelter’s assessment of the technical issue encountered exporting images via FTP syndication is close to what transpired. The syndication subsystem simply could not keep up with demand during peak times of the day. DRR staff (or former staff) were monitoring to a degree and taking action, but keeping systems healthy became impossible when access to office equipment, VPN’s, and DRR engineering tools was no longer possible. At no time was access to images deliberately blocked, as has been claimed elsewhere (not by Allen or Photoshelter).

“It is easy to see how DRR’s demise can damage people’s belief in the entire space for online archiving, portfolio, and digital storefront providers.”

Agreed. It’s my hope that faith in the space and innovation around it are not damaged for the long term by our story. DRR’s fate is not a result of the business we were in, or the platform we built, but a consequence of strategies and gambles often taken by early-stage business in order to grow. In our case, accumulated risk and recent severe economic developments combined to close off one opportunity after another, until none remained.