Refining and Refreshing
We just launched a refresh of the content on our main site – do check it out! While the changes aren’t very drastic, they do reflect a significant refinement to how we do business and I wanted to take the opportunity to talk a bit about why we made them…
As any business owner will tell you, two years of running a business will net you a lot of learning, and that’s certainly been true with Terralien. As I’ve worked with clients and crew members over the past two years, I’ve been able to start recognizing some patterns in the requests that we get, and in the expectations that our clients have. In particular I’ve found that our clients highly value three things: insight, predictability, and transparency. Every successful Terralien project has had a high level of these three things, and every failure of any size has been lacking in one or more of them. I’ve come to realize that if Terralien can consistently deliver all three, we stand a good chance of making each and every project a raging success, which is of course our ever-present goal. So how are we addressing each of them?
In the area of insight one of the primary ways we’ve failed in the past is at the start. We’re not big fans of lots of up-front planning, but me whipping out an estimate in a couple of hours was not cutting it. Part of the difficulty is the snow-ball effect – if the project gets started off on the wrong foot, it’s a lot more likely that things will get worse than that they will get better. Thus we’ve started going through an explicit product outlining process with most clients where we spend some quality time understanding what needs building before we try to build it. As an added benefit, product outlining generates portable insight: clients can take what we learn and use it to get estimates from shops other than Terralien. Definitely check out the details.
Predictability is a real conundrum since we haven’t yet figured out how to predict the future, and reading “Prognostication for Dummies” didn’t seem to help much. Regardless of the difficulties, though, this is one of the most immediate concerns clients have, and every project starts out with the same questions: “How much will it cost and how long will it take?” While we can’t predict the future, past experience has taught us that we can almost always launch a useful product in about two months. We call these two month time boxes launch cycles and we’re finding they really help clients to both know what their budget will be for initial launch and to stay focused within that window.
Finally, there’s the all-important quality of transparency. Transparency isn’t so much about one big thing; rather, it’s about a lot of little things that add up to a big thing. If a client is paying us they deserve to know how the work is going and to feel comfortable with our progress, and there are lots of small ways we’ve learned and are learning to keep them in the loop. Most important is just making sure they’re comfortable telling us when they’re not satisfied so we can fix it, and I personally am learning a lot about making myself open and available to hear the concerns. It’s not always easy to do, but it’s always worth it.
We’ve really tried to capture the essence of these things in the site refresh, so please have a look and let us know if we’ve succeeded. Feedback is always welcome!
I’m currently hanging out at BarCampRDU 2007 and having a blast. BarCamps are “unconferences”, which means the talks are proposed and given by the attendees on the day of the conference. Rather than just soak it all in, I decided to throw my hat in to the presenting ring and do a redux of the Camping in 10 talk I put together for Raleigh.rb a little while ago. After getting through a few projector struggles, it went really well, and I was able to expose about 30 people to Camping.
A few folks asked for my slides, so I threw them up on the interwebs, and you can get them here: Camping in 10 slides. Enjoy, and if you attended the talk and end up writing a Camping app of your own, drop me an email or a comment and tell me about it – I’d love to see what folks come up with.
So the tricky part about proposing a talk so many months in advance is that you never know what you’ll have learned (or not learned) by the time the conference actually rolls around. Back in November when I proposed my RailsConf talk, I was thinking that by now I would’ve reduced my sales and marketing efforts down to at least a general outline I could share with those at the conference. Boy was I wrong! The more I work to land projects, the more I realize that at least in this business, each sales process is unique as a snowflake. Yup, that’s right, the “MVC” pattern I put in the abstract is really clever, but turns out to not be very useful, at least for me.
So where’s that leave my presentation on Saturday? Never fear! Because while snowflakes are each unique, they do share common properties. So what I’m going to do is switch from focusing on a process, and instead do my best to pass along the tips, tricks and rules of thumb I’ve picked up over the last year and a half of selling Terralien. I might not have a useful system for selling custom software, but I sure have a lot of great “lessons learned” that I think everyone at the talk will find hugely valuable.
Upon figuring all this out, I was left with one problem: how do I structure the presentation? I mean, c’mon, every presentation needs a gimmick, right? After much mulling, I struck upon the perfect approach a few days ago, and instead of doing a plain old boring presentation, we’re going to do a super-agile game show! That’s right, we’ll be playing Sales Jeopardy!, with actual cash prizes to boot. Of course, not being a rich TV show, the prizes will lose a few zeroes off the usual Jeopardy pay-out, but hey, somebody might be able to at least buy themselves dinner ;-)
Hope to see you on Saturday in Portland!
I don’t want to dup the whole post, but in case you don’t follow my personal blog, I just posted over there about the upcoming Ruby Hoedown 2007. Have a look and make sure to sign up for the announcement list if you’re at all interested in coming. See you in August!
module Enumerable
def collect_one(default=nil)
inject(default) do |d,e|
if v = yield(e)
break v
else
d
end
end
end
endSo this:
element = %w(a bb ccc).detect{|e| /b/ =~ e}
size = (element ? element.size : 0)Becomes this:
size = %w(a bb ccc).collect_one(0){|e| e.size if /b/ =~ e}Discussion starter: does the name communicate?
