Untitled document
Yesterday I decided to document my journey of managing software development but I had no idea how much I would learn in just under 24 hours. For starters, I've never prepared myself for an Outlook folder containing "Partnership Opportunities" to have a four figure count of new items as we average a few dozen a week, tops. Second, the word free brings out so much me-too-ism that it begs asking the question of which point actually sold them on the product? I'm an admitted fatass but even I step back and look at what I'm being handed while walking around Costco (they give out free food samples while you shop, yes, its THAT great to live in America). Just because something is free it doesn't make it a good idea. Anyhow, here we go with the lessons so far that begin before anybody sees your product:
Answer the FAQ before someone asks the question
Putting up a wiki takes just a few minutes but saves hours and hours of thread responses and cut&paste activity. Point being: anticipate what your testers are going to ask and document it up front. Doing so puts you in the right frame of mind because you will no longer try to explain the feature or concept as you would to a computer (through pragmatic development, syntax, error checking) but to an actual user. If you do that, you will likely find where you as a human are making the mistakes of relating too much to the computer and too little to the end user. After all, its all about the user experience, right?
To this point everything about Shockey Monkey is sight unseen. It's Duke Nukem: Forever as far as everyone is concerned. So it is important to detail the core concepts of why you are creating this software in the first place. What problem will it solve?
Give people a place to go
Just because they wanted it yesterday does not mean they will ever pay for it tomorrow. Just because you make it doesn't mean they will come. That is the sad reality every shareware author realizes initially. However, the opposite is true as well. Perhaps I struck someones imagination yesterday but they were between trying to find a dip recipe and flipping the burgers on a holiday weekend. I'm sure they bookmarked the post, either physically, mentally or via email and thats where the thought ends.
This perhaps was the biggest mistake of all, not having a place to send people off to so they can keep in touch with the project progress. No RSS feed, no web page, no wiki, nothing. Now my circumstance is limited because I just dropped the hot soup into the lap of a site with tens of thousands of daily visitors, but its a good practice to hold nonetheless and one I just learned today: Give people a place to go.
Make yourself available
Someone asked yesterday if there was a chance that the livemeetings would be recorded. I most certainly hope you never succumb to that pressure (or that of a spell check since I have no idea how to spell succumb) because at least initially you are just dying for fanboys. You need people to cheer you along the development cycle but you also need all the eyes you can get. What good is it to just hand out a PR webcast for something that does not yet exist? Thats great for something you are trying to sell but as you're writing the software you need all the help, advice, opinion and angle you can take.
How do you intend to use this software? What would make it easier to use? Here is what we were thinking when we did this, does it make sense? What would make more sense? In which situation do you think this would be applicable? How do you work?
MicrosoftBS has a very nice marketing campaign titled "People Ready" where they talk about how they write software that "works the way you do". Now for a moment just pardon the fact that this message is totally separated from reality, much like most of MicrosoftBS, and focus on the idea of it. You initially identified the problem and tried to solve it – but along the way you can find out from others with the exact same problem and hear their solutions. Yours may not be the best, so be there to hear their opinion too!
Control the experience
This is a biggie. For most software "controlling the experience" is limiting the distribution to the specific people that may be qualified to break it and provide feedback. This is something I learned just recently from the Microsoft Exchange team. Steer people in the direction where you are seeking feedback. That is, hold a webcast. Show a specific feature. Now that you've seen the feature, what do you think? How will you sell it? Why won't you sell it? Where do you think it will solve the problem? Don't just aim to control who sees your previews, aim to control in which light the features are seen.
Ask the stupid questions
If you were brilliant you wouldn't need to beta test your software or patch it, ever. But we're all flawed, whether by design or by the experience, so try to ask the stupid questions. Here were some of mine:
Do you like this shade of blue? Do you ever encounter the business that looks at their IT this way? Is this something you'd ever customize? Are we on the right page with this one? Who would do this?
For example, Shockey Monkey has several classes of users each with authorizations to do different things. There is the Administrator and Staff member that work for the IT Solution Shop. There is the Accountant that is not interested in the Helpdesk, just how much we need to bill. For the client we have a Client Administrator (their IT guy that does on-site work, controls who gets to report problems, etc) and the end user, Client. Now this is going to sound stupid but I never forsaw a reason to give Client Administrator the right to add users. Sure, thought of a reason to allow them to escalate tickets, answer tickets on their own, add knowledge base articles, everything but manage users. One gentleman said today that it would save him a ton of time if he could just delegate that client employee management to the Client Administrator. Another remarked that:
"some of my clients change employees more often than they change their underwear."
So don't be afraid to step out of your comfort zone of only discussing your ideas and be open to the ideas your customers bring up. Sure, it might be a huge chunk of functionality that you will have to develop, test and manage but its your duty to make the software people want to buy so you better be open to that feedback.
Thank the cheerleaders first
Oh lord does coding suck. Today I looked at the same 120 lines of code for about 10 minutes before I found what was producing this obvious debug report to be displayed even though I had switched off the debug flag. It just kept on printing the "ticket total" number and I could not find it. So I went through the code commenting half the module out with multiline comments and I found the bug. Whats disheartening is that this wasn't some nasty hidden bug that would have taken a ton of time to isolate. It was just a single line print statement that anyone else would have seen a mile away from my desk. I've been looking at this code for days and it took me 10 minutes to find it.
Development ain't easy. When you get the joy of being in touch with the people that use and benfit from what they do suck up all the cheers and positivity you get. Each atta-boy is worth 50 headbangs against the table 🙂
Conclusion
CIS & MBA degrees didn't prepare you for that, did they? Now obviously this is not something that is ever going to be seen in the academic materials but if you're a coder and looking for some more real world software development information take a look at a great book written by Scott Berkun: The Art of Project Management.
Sometimes beta testing, or pretending to, pays off. Such is the case of Windows Live OneCare, the all-in-one security and safety service from Microsoft integrating the antivirus, antispyware, maintenance (defrag) and backup functionality. This is Microsoft’s first significant push into the retail security space with a consumer product, 