August 30th, 2009 Chris
in reply to steveneville1 #Posted in Blog | No Comments »
August 23rd, 2009 Chris
Posted in Blog | No Comments »
August 9th, 2009 Chris
Posted in Blog | No Comments »
August 2nd, 2009 Chris
Posted in Blog | 1 Comment »
July 26th, 2009 Chris
Posted in Blog | No Comments »
July 24th, 2009 Chris
OK, I know it’s software…
So, about two months into the development of our software application, we had the inevitable one month slip once everyone understood the requirements. And it was pretty much all my fault…
Because we kicked this off while we were still in Miami, I went through great lengths to define requirements in gory (ie. requirements document) and somewhat intuitive (wireframes) ways.
However, two months in, we realized that myself and the small team here in Ottawa weren’t quite on the same page. What it took was a long white-board session in which each major functional area was walked-through and dissected.
Again – not a huge surprise that there are hiccups in the development of a new app. But what struck me is the only reason this got back on the rails was the fact we could sit down in person and sort it all out.
That lead to another question: how does a micro business not blow their brains out outsourcing development. I mean at the end of the day someone needs to be local who understands what you’re trying to accomplish. Perhaps that’s why often it’s more often Q&A work and more “mundane” dev work that gets farmed out…
All I can say is saving on outsourcing, 30% (maybe). Looking your developers in the whites of their eyes… priceless.
C.
Posted in Development | No Comments »
June 4th, 2009 Chris
As I’ve mentioned on many occasions, what works and what doesn’t is often a complete mystery when it comes to on-line marketing. I’m sure it has to do with how our brains are wired and we respond to one stimulus versus another.
The best that I (and most on-line marketers) can prescribe is to do these three things: 1. Test, 2. Test, 3. Test some more. That is the best (and often only) way to figure out how to optimize your marketing efforts. And of course steal ideas of people that have done the testing for you!
So this week I thought I’d share a couple of my lessons learned from recent email marketing testing…
Lesson #1 – Subject Line
I hate to actually share this since the more people that do this, the less effective it will be… We did an experiment where we put the source of the email on the subject line of our newsletter blast. You’ve probably seen a few in your inbox like this.
Specifically, we tested Subject: [Engage] Engaging Ideas versus Subject: Engaging Ideas.
Turns out that by putting the [Your Company Name] in the subject line, we found open rates increased by over 5%.
I can rationalize these results with my own observations that emails with this consistent subject start stand-out from the other clutter in your inbox. And as users become more used to seeing it from you, they are more likely to automatically open them.
Of course the downside is that if you spam your users to much, they are also more likely to automatically ignore your emails with this method. So, as always, always try to give your readers something valuable every time you hit them…
Lesson #2 – Embedded Links
Virtually every call to action with email marketing involves a user clicking on a link. And of course we always try to make it look pretty by having the actual link URL behind the scenes. It makes the email easier to read and allows a more directive call to action – ex. Click here now!
But what about folks that have been programmed to not click on links in emails due to security concerns? What about those people that have screwed up their MIME settings and when they click, it just opens a browser but doesn’t go to the specified URL (my browser was like that for two months recently…)?
What we’ve started to do is include both the embedded link as well as an explicit statement of what address to go to. Here’s a recent example:
The results: we receive about 10% of the actions from people that copy and paste the link in their browser versus those that simply click the embedded link. That’s 10% of folks that we wouldn’t get otherwise.
Well, that’s it for today. More testing to follow…
Got some of your own test data – leave a comment and share!
C.
Posted in E-mail, Marketing | No Comments »
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 »
