Tag: alpha

Making it Epic (alpha edition)

“If you’re not embarrassed when you ship your first version you waited too long.” ~ Matt Mullenweg

On Tuesday evening, James, Alan, and I linked arms, cringed a bit, and hit send. The first batch of invites to the Epic.io private alpha were out.

Already we’re learning a lot. As ’embarrassing’ as some of the things we see are, what we’re gaining from real-world usage is worth it. Feedback has been real and is helping us prioritize what needs attention most.

At the same time, the gulf between what we are tackling and what we are showing is huge. The messaging of Epic.io is, well, pretty epic. It’s big and bold and ambitious. It’s risky too. Is it setting the expectations too high? Does it create too much dissonance between the promise and the user experience? Maybe.

But I’d rather be bold and be out there. Vulnerable in our ambition. Inviting in our mission.

Purpose is at the heart of all initiative, organization, and systems. If we succeed in making purpose the platform we  succeed in making that reality actionable and useful to people every day. And that should bring less noise, more meaning, and ultimately, fulfilment of what matters to each of us in our work and in our lives.

Life is too short for bullshit. We don’t know where this will go, but we do know why we’re doing it. So if that resonates why not signup, see what it means for you, and tell us how it can make purpose the platform.

Let’s make it epic!

Enhanced by Zemanta

Alpha, Beta… Public

In this world where web apps can be built, launched and iterated quickly we’re seeing more and more of the perpetual beta. Even most of googles apps carry the ‘beta’ tag long past when my usage experience seems to be bug free.

One side of me says, forget the distinction… of course it’s always beta… if it’s not it’s not evolving. Another side, says it’s about managing expectations, as in “Don’t throw things at your computer (or me) if this doesn’t work as you want it to.”

As we work onBy launching thread.io I’ve been pushed to figure out some sort of rationale for our ‘readiness status’. In trying to balance our desire to iterate rapidly in public and at the same time indicate what users can expect from the service, here’s what I think we’re going to go with:

  • Public Alpha: We’re got some minimum basics but are still working on our core tech and interface. We prefer ‘public’ so we’re opening it for experimentation by anyone who wants. Expect frequent #fail.
  • Beta: Here we’ll have developed our core tech and features and will be  working hard on scalability and prioritizing new features. Expect the occaisional #fail.

For sure we’ll be going live early. Earlier than I’ll probably be comfortable with but I keep finding that every time I push something to the public I get benefits that outweigh the costs. I wonder what’s ‘too early’ – I just hope we don’t find out.