So many mistakes (yet so much fun)

Patrick here.

Launching Tribbon at Business of Software was an amazing experience. I worked several weekends and many late nights getting it ready – I knew it wasn’t as far along as I wanted, but I was surprised by many of the things I learned.

A friend reminded me that “if you aren’t embarrassed when you ship, then you waited too long!” Well, I was definitely embarrassed … but I still think I waited too long! This “iteration” probably took 10 weeks. At the beginning, I didn’t understand how I could have made it any smaller, but by the end I clearly did. It wasn’t until after I spent a significant amount of time building tweet functionality that I realized how much more important basic “human contact” functionality was. Twitter exists already – the connections I was trying to facilitate didn’t. I could have run a more basic test in maybe 2-4 weeks. I think I learned my lesson here, and I’m definitely going to strive to have tighter iterations from now on.

The impact of this mistake showed up in the “most requested feature” that was next on my list: the ability to find people with similar interests (vegan, runner, Windows Azure user, whatever). The reason I didn’t get to that feature was partly that I didn’t prioritize correctly, but was more specifically due to an even more egregious mistake:  caving to vanity and implementing a new visual design 2 weeks before the event. We worked with a designer/developer on our marketing website (where we also spent way too much energy in retrospect), and his design for our web app looked a lot better than what I came up with on my own. I remember thinking, “oh, this will only take a day or two” – but my estimating was based on my instincts from working on something full-time (instincts that were never all that great anyway). My Tribbon workday doesn’t start until my day job is over. I’m usually pretty exhausted and am lucky to get 2 or 3 hours in. Bottom line, changing designs took slightly more than a week and prevented me from implementing a highly requested feature. That robbed us of potentially valuable learning.

At a more micro level, there were many things that simply could have been learned earlier at smaller events. For example, I didn’t know that QR codes have such an inconsistent user experience across devices. It has a great experience on my device (a Windows Phone), so I assumed everyone had at least a decent baseline experience. After all, those little codes are everywhere. Watching someone try to scan our QR code on their brand new iPhone 5 was eye-opening. They were using a free app that had ads at the bottom and made the site even jankier than it would have been otherwise. Horrible. Totally not worth it. QR codes are fine if you are building support into a native app and can control the user experience, but for web apps, I think they pretty much suck. I could have learned that a lot earlier and a lot closer to home.

I also simply overestimated the baseline level of smartphones at the event. There were a lot of people sporting low-end Android devices and Palms and Blackberries … some of these people were our most important users! Yet I used all kinds of fancy jquery/bootstrap stuff because I love the way it looks. That stuff is great if you KNOW exactly what browsers you are targeting and can test appropriately, but I didn’t. Bad choice. Given our limited resources, we should have chosen a simpler baseline for a mobile site (simple html/css without html5 features or lots of javascript – and use images for icons instead of fonts). In the future, I’ll also be quite precise about what desktop (and tablet) browsers I’m targeting and just test more. I was just way too loose there. It felt amateurish, and I hate the way that feels.

As Jody mentioned in a previous post, we just bit off more than we could chew. I’d rather do one TINY thing really well – or do one SPECIFIC test rather than trying to deliver a bunch of features that haven’t been proven together. In total, I delivered something janky and unusable and didn’t really get a good test out of it (although we got a lot interesting feedback and ideas, and we learned a ton from just watching people).

One more criticism – I was really surprised to see an “enterprise tick” of mine show up (most of my development has been for business software, not consumer apps). The menu I chose was “people | tweets | me” – it made perfect sense to me but not to anybody else! It would have been better to use something like “who’s here? what are they saying? tell people about yourself” – it reminded me that I need more design help when dealing with consumers.

The onboarding experience was embarrassingly bad. Multiple people asked, “now what do I do?” Again, that’s great to learn and see firsthand, but it sucked not to be able to do anything about it. There were too many flaws to fix while I was there – I decided it was better to absorb the conference and regroup afterword.

Finally, a funny little bug. The ONE thing that was almost useful was the tweet stream. The wifi was really bad, but my backend tweet handling was actually pretty good, even though the user interface for this feature was spartan AND incomplete … but I quickly realized it was unusable because I messed up the sorting. Although I was getting and saving tweets from Twitter in real-time (using the streaming API in a Windows Azure worker role), the web client was just polling my server (Windows Azure web role) once every minute. But I hadn’t tested with a busy hashtag! It was “working” on #bos2012 for weeks before the conference, but I never saw what it looked like when receiving more than 1 tweet/minute on #bos2012. Turns out that I reversed the sorting WITHIN each minute, so the net effect was unusable. Doh! I saw a wonderful presentation from William Pietri a couple of years ago about the difference between disposable and sustainable code. While you’re running experiments, code is disposable – it’s not until after you know WHAT you’re building is right that you should switch to sustainable code in a startup … I embrace that thinking, but I crossed the line by not testing this feature enough. I’ll work to rebalance that.

All of these things were useful to learn, but there was something much bigger. Something felt “not right.” During and after the conference, I asked several of my wonderful advisers about my approach. I won’t go through all of the painful reflection, but I’ll summarize by saying that I realized I had forgotten the advice of Steve Blank, Hiten Shah, and others: “Fall in love with the problem, not the solution” (I don’t think Jody fell victim to that as much as I did). I had indeed fallen in love with my idea of a solution for connecting people at events and making events more memorable. That’s not how you build a business. You build a business by finding the people with a problem that they are willing to pay to fix, then you talk to them about it (ideally getting their money up front) and then you lovingly deliver what THEY want, not what YOU want. I’m a bit mad at myself for falling into that trap, but maybe I had to in order to really learn the lesson.

So while I was tempted to start fixing bugs and improving my solution, that’s not what we’re doing at the moment. Instead, we’re stepping back for a week and revisiting the problem. Who is our customer? Who do we want to “make badass” as Kathy Sierra put it? We have several options: conference organizers, attendees, speakers, sponsors … none is wrong, but it’s not a question to hedge on. It’s also not a question I can answer on my own, so I’m working with Jody, and we’re getting help from advisers that are more experienced than we are. We’re also getting help from a designer who is a user experience expert. It feels extremely uncomfortable to step back and experience this uncertainty (I want to build!), especially as we just received a small amount of funding from Start Garden. But we have to do it. If we’re going to succeed, we need to focus on the problem more than our solution, decide who the customer is, and run short experiments to validate/invalidate our hypotheses. If we do that, then it’s a matter of time and determination. If we don’t, then it’s a matter of hopeful guesses. We’ve made our decision to go in that direction, but actually doing it is harder than I ever imagined.

There is one thing I’m personally very proud of related to our launch at BOS: I didn’t shy away from the suck. Our product sucked at this event. Much of the suck surprised me. Some of it prompted a facepalm. Some of it genuinely hurt my pride. In the past, I may very well have responded to sucking by hanging my head and deciding that I wasn’t good enough for this. Not this time … I never hesitated. Yes, it sucked, but it’s not going to suck permanently! And it doesn’t mean WE suck – IT sucked! We’re learning from our mistakes and adjusting! That’s incredibly empowering.

(EDIT: OK, perhaps I subliminally shied away from the suck here in that I never linked to the app! It’s http://tribbon.com/#bos2012. I’ll make sure to save it in its current state for posterity when it stops sucking …)

I’m quite certain that Jody and I will succeed as entrepreneurs, although I don’t know if it will happen with Tribbon as we currently envision it. Our experimenting and adjusting might take us in a completely different direction (perhaps more than once). We’re going to fail a LOT along the way. We’re going to suck sometimes. I want to share that, because I think it’s important to see that mistakes don’t have to be fatal. They DO hurt. A first effort might really suck. That suck really IS embarrassing. IT FEELS BAD. But in the end, it’s no big deal. I’m trying to see reality as it is, feel what I feel, and then just keep plugging. Persistence is what will make us win.

Thanks for joining Jody and me on this journey.

And as Jody said, thank you SO much, Mark Littlewood and Neil Davidson for including us at Business of Software 2012!

Patrick

BOS2012 Personal Lessons Learned

Hi, It’s Jody again. Wow. I am just now recovering from the whirlwind of Business of Software 2012. It was the most exciting, exhausting and rewarding event so far.

This is the fourth year for me as an attendee but the first year as a founder/entrepreneur. Words cannot express the difference in mindset. Instead of having conversations in my head like “Wow, I wish so-n-so was here to hear THAT” and “How am I ever going to convey that awesome point to others back home?”, I was able to actually focus on how I would use the ideas right away. Like… in real life. Starting tomorrow. Amazing!

Real-time collaboration. Having a partner sit next to me to scribble ideas back and forth with during the presentations was also amazing. I came home with far fewer official “notes” than ever before. Instead, I have a handful of “decisions” and some “discussion points” to visit later. I felt like I had super human processing powers just by having a great partner sitting next to me (this is the part where Patrick’s head explodes).

You hear what you want to hear. Listening to stories of those who have walked the path before me has always been an inspiration. This year was no different. However, I also heard cautionary bits of wisdom that I didn’t quite pick up on in years past. Maybe because I wasn’t paying close enough attention. Instead of hearing “you can do it” and “you got what it takes”, I heard things like “be careful of this” and “watch out for that”. Holy cow! What a difference a little perspective makes.

Looking back. I truly appreciate all the years my previous employer, TechSmith, sent me to BOS for “professional development” reasons knowing full well I’d probably come home someday and announce that I had found an alternate path. My only regret is not doing a better job of sharing the wisdom I gained at BOS with my colleagues all of those years. TechSmith was once a startup but has grown into a successful 250+ person company that struggles to hold onto its entrepreneurial roots and culture. I continue to wonder what I could have done differently and if I really tried hard enough. I will always care and I will never forget what it was like to be part of that team.

People are everything. Unfortunately, I can’t remember everyone’s names and faces as much as I can remember the feelings and experiences we shared together.That is SUCH a shame. I want to remember the people too! As many of you know, we were testing Tribbon at BOS this year and thought we were on the right track with lots of half-baked features that sort of hinted at solving this problem. Turns out we were wrong. What we needed to do was scale back to the one thing people cared about, which was remembering each other and the context in which we shared the experience. So today we pivoted. It was a big deal, but it totally feels right and I can’t wait to start working on the new thing tomorrow.

There were a bazillion other valuable pieces of information I picked up from the amazing speakers, attendees and BOS staff that I did not mention. I truly feel blessed to be part of this wonderful community and I am already looking forward to BOS2013. Thank you Mark Littlewood and Neil Davidson and your awesome band of pirates for making it all happen. See you next year!

Jody

Late night lessons learned

Building a startup is all about learning. “Build, measure, learn” is the lean mantra. I’m learning a ton building Tribbon with Jody, but I’m a bit surprised at how many of the lessons are “foundational.”

For example, my most trusted advisors – people like Jason Cohen, Ash Maurya, and Rob Walling – always talk about running small experiments where you can get answers pretty quickly. I knew that intellectually going in, but I hadn’t really experienced it.

After many late nights coding Tribbon to get it ready for the Business of Software conference, I think I figured it out. Now I really KNOW what they mean by running smaller, tighter experiments. I’ve experienced the pain of doing it the other way, so I don’t just know it intellectually.

A couple of months ago, it made perfect sense to go heads down and make a “minimum viable product” for the conference to see if attendees would like it. In hindsight, I let my pride and my perfectionism – both good things – keep me from running smaller experiments. Instead of coding for 6-8 weeks and launching a still-imperfect product the day before BOS, I should have started here on this blog, simply telling people what I was building. Then I could have done “traditional” 1-week agile iterations and had something to show each week.

Our “fans” – the people who are going to BOS, care about what we’re doing, and want us to succeed – would then have given us feedback all along the way. We would already have had 6-8 weeks worth of feedback instead of just starting that process now (while I’m physically exhausted to boot). People attending BOS would already have known about Tribbon and might have had a clue about what it could do for them. Instead, we’re starting the whole explanation process tomorrow as well.

Lesson learned. We need to run smaller experiments and include more people in the process along the way. I don’t think I’ll make that mistake again.

But there’s another thing I’m learning – it’s less important to be perfect than it is to be persistent. This is just the first in a long series of experiments that will lead us to building something we want to build that customers want to use and pay for.

I’m having a blast and can’t wait to see all my friends at #BOS2012. Time for sleep. Tomorrow, we launch!

Getting out there

Hi – Jody here.  I am getting ready for the Business of Software Conference next week. Can’t wait to see old friends, catch up on trends and do some product testing and market research for Tribbon. Oh!  And I am doing a lightning talk this year about living fearlessly so I am even more jazzed than normal.

Patrick (my cofounder, developer and super-CEO) has been up late nights working hard to get Tribbon ready to show and test at the conference. It has been both impressive and painful to watch him juggle the demands of a full time day job, travel, family, unexpected technical glitches and a nasty head cold in the process. Oh, the glamorous life of a startup.  😉

We will be demoing and talking about Tribbon at BOS for anyone who would like to check it out. We might even have a version for you to try out for yourself by then. Stay tuned! Feedback and suggestions are being gathered at uservoice.tribbon.com. Feel free to go there and share your thoughts now or later.

As a marketing professional I have to admit, I am learning that there are vast differences between what you do for a start up and what you do for an established company. What an awesome adventure! I will start sharing some of my lessons learned in upcoming posts.

In the meantime, here is a summary of the tactics I am deploying for this event.

1. A blog to communicate updates and other good stuff (you are reading it now)
2. Some well-timed tweets on the conference hash tag (#BOS2012)  leading up to the event.
3. A customer feedback mechanism (I chose Uservoice because they had a great mobile experience)
4. A basic website with a decent product description:  www.tribbon.com
5. Branding stuff.  Biz cards & t-shirts with QR code, elevator pitch, etc.
6. Speaking gig at the event to draw some attention (AKA: 400 hours prepping for 7 minutes of torture :))
7. Be present and helpful at the event.
8. Analyze the results and decide what to do next.

So that’s the plan. I am sure I haven’t nailed it completely. I know I must have missed the mark on a few things or overlooked some altogether. But I am willing to make mistakes to learn. THAT feels pretty darn good.

Let me know what you think.

Jody