Slipstream Dev Process

May 27th, 2009 Chris

I was visiting a friend of mine posted to NATO in Brussels over the last week (OK, visited for two days and went to Paris with Colleen for the rest). He was lamenting the use of PowerPoint in his job and I had to agree. In my former corporate life, PowerPoint was the way of communicating. Didn’t matter how complex the issue – it would be boiled down to a few bullets on a chart.

There is a very cool design guy my friend Eric introduced me to, named Edward Tufte. He wrote a great book called The Cognitive Style of Powerpoint: Pitching Out Corrupts Within, making the argument that the typical charts only serve to weaken verbal and spatial reasoning, and almost always corrupt statistical analysis.

However, I did find a new use for PowerPoint in a development process we’re using for the stream-lined MicroBiz Development Process (MDP – a new acronym!). Why a new development process? Well – I guess the long and short of it is that the traditional development process I’m used to is way too slow and expensive.

I’m used to writing long, gory specifications, complete with personas, etc… and handing it off to a development team for detailed functional specs, design specs, UI specs, QA plans, etc… Those are great if you can have millions to spend and 6-9 months. I have neither…

Instead, with the MDP (wat dat? oh yeah…), the goal is to compress these activities by leveraging a very important factor – a detailed and clear picture of what the application will do in the mind of the “Product Manager” (aka me).

Traditionally, I’m used to letting the gory details of the application get sorted out by the experts as part of the discovery and specification process. If we want to compress that, it means that I have to have a very clear picture of what the app will do and how it will do it. That cuts out a bunch of steps although still leaves the risk that one develops something that then blows up capabilities or the schedule or the cost or all three…

So what did I do specifically? For our app, I create two documents… 1. A high level specification complete with a list of functions that the app has to do that and the role of the people who do them. This is pretty much like a standard requirements document except I focused on the stuff that was behind the covers (performance, scalability, security, etc…).

2. The second thing I did was what really made this project fly… It was to dust off PowerPoint and used it to create a UI wireframe. That is, to go through and show the various screens that the app presents. In my case, I had one section for the end user and one for system administrators.

It was an incredibly effective but laborious process. Each screen was mapped out including what info would be presented and what actions the user could perform. Essentially it was compressing the requirements spec and UI design into one document. Along the way, it forced me to examine every aspect of functionality – essentially reducing each user interaction to a series of inputs, a series of processes, then a series of outputs.

Was this the final UI design – nope. That the dev experts can work. But what it clearly showed is what the application needed to do and the wireframe was close enough to the UI design that it was a relatively straightforward transition.

But coming up with the wireframe slides was a painful process  as it required a very crisp view of what the app was to do. It took me at least five run-throughs till I was happy with the 80-slide result.

Then the real payoff occurred. The MDP relies on rapid prototyping. That is, quickly implementing somewhat rough hunks of functionality for review and testing. With the Powerpoint wireframes, the dev team was able to crank out the first half of the app (ie. about 50% of the functionality) in only three weeks. And they’ll have the whole thing ready for alpha in another three weeks.

So six weeks from delivery of these documents to a fully functional alpha… Pretty cool. That, combined with some intensive testing by the Quality Assurance team (aka me), and we’re developing this application faster than I would have ever guessed was possible.

Now, will we hit speed bumps that impact our cost and time and effort? Absolutely – that is to be expected when moving so fast.

Is it still an order of magnitude more efficient for us than the traditional large company dev process? Absolutely.

We’ll see how it goes – only two months till beta and four months till commercial release. What could go wrong? (oh yeah – it’s software…).

C.

Posted in General | 2 Comments »

Hired Guns

May 14th, 2009 Chris

As I said last week, I’m getting back into software. And to answer the question I got from several of you, I’m not yet disclosing what it is going to do. We’re still a few months away from launch and I don’t want to tip any potential competitors…

One of the biggest fears I had in getting into all of this was the tremendous investment I feared would be required to actually develop the code. I came from the world of big enterprise software where development is slow and expensive.

Not that the developers weren’t fantastic – they were talented and opinionated, very opinionated It’s just that the paradigm was different. Big software releases happened every year or two, had tons of new features, had to run on multiple platforms and had to be bulletproof.

So when I first developed the concept on the app we’re developing, I assumed that it was going to cost a lot to build – originally I assumed at least $50k – $100k. What I soon discovered gave me the encouragement and cash to go ahead with the project…

Two key aspects of our project substantially reduced the development cost:

1. Software as a Service. We wanted to build this app as a service versus the old fashioned download-install-run model. That meant no multiple platform requirements, no installer, etc… All the stuff that adds tremendous cost without value for the customer.

2. Built in Product Manager. We were not looking for a full-service development house that had project managers and extra layers of overhead. I wanted the type of relationship I was used to: me as the product manager and our hired development guns as the development team. That eliminates a lot of overhead cost.

So I did up my specification (more on that in a later post) and went out to collect a couple of bids… And was blown away by how little this was going to cost!

I should note, that I didn’t go off-shore as I wanted to see the white’s of the team’s eyes. I wanted to sit down over a beer and make sure we all understood the requirements. I want to sit down over a coffee and make sure that the schedule is one I can count on. I was worried that remote development would add a bunch of barriers to communication that would counter-act any cost benefits.

In the end, I found a great team right here in Ottawa who gave me an aggressive but credible bid. And we’re off to the races.

Of course, this is software development so schedule and requirements churn is to be anticipated. But because I’ve got the right team and the right price – I know we’ll get there in the end.

In fact, this model is quite liberating. With the barrier to develop so low, the consequences of failure (from a sunk cost perspective) is also quite low. Which means that if one project doesn’t succeed for one reason or another, you can always try again with your next great idea…

Although that won’t be the case for us – this one’s a winner!

C.

Posted in Financial, Technology | No Comments »

Revenge of the Nerd

May 6th, 2009 Chris

Over a pint (quelle shock) with a buddy yesterday, I was bugged about my lam-mo blog posting frequency of late. And the jab was well deserved. I have been very lame…

I could justify it by saying that we’ve been very busy: our Powerhouse Event was last week (with double the attendees of last year!) and Colleen’s new book is hitting the book stores (go to honestysells.com, now!).

Those items (listed above purely for promotional purposes) have taken a lot of our time but the real exciting news is that we’ve decided that I get to be a nerd again… That’s right, we’re getting into the software business.

I have to be honest: I love the software product business. But based on my experience at my former employer, I thought that it was mutually exclusive with the lifestyle that Colleen and I have grown to love. Too much money was required to launch a product, too much effort was required to market and sell, etc…

But then I started to run into folks that were launching software solutions as micro-businesses and I was inspired. Development could be done inexpensively. Sales and marketing could be done cheaply yet effectively. The big difference is the goal: no desire to go public and make tons and tons of cash. Instead the goal is to launch a product that does relatively well, provides a revenue stream and allows for the continued   lifestyle.

So, Colleen and I agreed on an area where a software solution could add tremendous value to our clients and we kicked off the project! But to do so, we agreed on a few core tenants:

1. Self Funded.

I don’t think I’ve ever heard a single person say, I love my VCs… We don’t want to deal with the stress of all that so the first criteria is that we be able to develop, launch and grow the product only with funds that we generate in the business. So no investors – we own it all.

Now it does help that our business is currently throwing off a bit of profit so we don’t have to borrow any from the bank on the ol’ Line of Credit at this point. But if some point we have to, that’s OK. As long as we don’t get ourselves into the position that any debt on the product could take down the company.

Does that mean the product won’t grow as quickly and we’ll not generate as much revenue. Absolutely! But that is the trade-off to keep it ours…

2. Lifestyle Preservation

I am addicted to our lifestyle. The not shaving or wearing pants on most days. The three months in Miami. The lack of PowerPoint in my life. And this project cannot change that.

So, we will need to do things virtually – working with contract developers. Getting sales and marketing help without hiring. Etc…

3. Complementary to the Business

At the end of the day, we need the product to be complementary to the business. That’s how we get a multiplier effect. We’ve got over 10K people in our database which is an amazing starting point to up-sell and cross-sell. And it means we can leverage Colleen’s high visibility in the market to promote this as part of our overall portfolio of services.

So in April, we pulled the trigger and began development. And we’re moving fast, aiming for commercial release in the fall.

I know there are a thousand things I’ve not thought about and will learn by trial and error… And I’ll make sure I share them all on the blog. Hopefully, together we’ll confirm that you don’t have to be a big, VC-backed company to successfully launch a technology product…

Next week: lessons learned in getting stuff developed…

Thanks, C.

Posted in General | 3 Comments »