An Experiment – Choose My First Product

It’s late, and I am positively delirious from lack of sleep.  I hope I don’t regret this post in the morning.  😉

I mentioned a few days ago that I’ve joined the Empower program offered by Microsoft.  Even before I joined, I had a ton of product concepts in mind.  After pondering the issue for a while, I thought I had identified the strongest concept from my idea-pool.  As of yesterday morning, I was all set to start doing some deeper market research to validate my conclusions, then start gathering requirements.

But a thought occurred to me yesterday, inspired by a lively stew of this JoelOnSoftware forum post, the Cluetrain Manifesto, and a recent Forbes magazine cover story – instead of charging ahead with my product idea, why not simply ask people what problems they’d like to see solved with a software tool?  It should seem bizarre, to think that coming up with a useful product could be as simple as asking “what do you want,” but with the rise of corporate transparency and the ever more commonly-held belief that markets are conversations, it doesn’t strike me as weird to begin that conversation by asking “how can I help you?”  After all, companies ask that very question in order to improve existing products.  Why not ask it before you’ve made any product?  Is this completely ludicrous, the idea of asking people what they want rather than clandestinely doing market research?

I don’t think it’s such a stretch.  Let’s experiment with the idea and see if it yields any useful results:  If you and I were sitting down over coffee right now and I told you “I’d really like to try to apply a software-based solution to one of your nagging problems at work,” what would you tell me?

Sound off on your blogs or in the discussion forum!

One Step Toward Joining The Ranks Of ISV-dom

I signed up for the Empower program offered by Microsoft a couple weeks ago.  Empower is a one-year program (renewable for a second year) meant to help small ISVs get ramped up on developing applications that use Microsoft technologies.  For $375, an ISV gets 5 internal licenses for Windows and Office XP, Windows Server, Exchange Server, SQL Server, SharePoint, MSDN Universal, Visual Stuido.NET 2003, etc.  It’s a great deal and seems like a good, inexpensive way for an ISV to get started as a Microsoft partner.

So now I’m committed!  The big rule of the Empower program is that you must a) announce and b) actually release a new packaged software application within 24 months.  I am whittling down my last two product concepts and will decide which one to develop soon.  I might even blog the development process, we’ll see.

For the record, I am excited.  Wish me luck!

Christopher and Valerie Talk Estimates

Having a great conversation with Val the C# Gal, thought I’d share.

So, Christopher . . . Not to back you into a corner, but if you had your druthers, how small would you like projects broken up? A month of requirements gathering, followed by a month of spec writing, followed by development, for example? Or maybe a week of each followed by a release? I am interested to hear what has worked best for you.

No, no – feel free to back me into a corner.  It’s a good way to get honest answers.

That said, my preference is to let each project tell me what kind of iteration period it needs.  Believe me, I know how hippy-dippy that sounds.  But it’s honest.  For example, once I complete a high-level set of requirements – the proverbial view from 10,000 feet – and it’s time to start drilling down, I’m not likely to say “let’s write spec for a month,” but I am likely to say “let’s spec out the garthok-gnarfling feature first.  And if the client agrees that it makes business sense to do so, and I have a high degree of confidence that garthok-gnarfling won’t break anything else that I need to build, I’ll test, document and deliver that garthok-gnarfling feature by itself so it can be put to use while the rest of the system is being built.

Mind you, this is just my personal preference – it is very important to me to get working product in the hands of the client.  I think it helps the client feel as though the project is real, not some intangible, abstract thing that will be delivered Q3 of 200x.  However, not every project lends itself to such tight iterations – usually two or three or more features will be interdependent in such a way that delivering any single one by itself is pointless, and this is OK.  I’m not a fan of trying to force reality to fit my own prejudices.

In general, some combinations of the client, the market, the business process, and politics will dictate what kind of iteration is needed for a project.  For example, I recently did an ASP project that had me delivering pages every week.  A few years back, I did a project for Exxon-Mobil that had me delivering product every 6 months for a couple of years.  Both projects were successful according to the performance measures set out at each project’s kick-off meeting, so it’s hard to say for certain that either approach is “better.”  Each project got the approach it demanded.

I realize that this does not answer your questions directly – you want a concrete “x is better than y” answer.  Problem is, I don’t think I have one for you.  But I can say this:

  • In general, shorter cycles of design/develop/test/release seem to work well
  • In general, design-it-all, build-it-all, test-it-all, deploy-it-all projects are more problem-prone
  • In general, prioritizing the most useful and least interdependent features leads to shorter initial delivery times
  • In general, most projects have artificially short schedules anyway, so don’t be shy about putting your foot down the next time someone hands you an estimate that is obviously inappropriate.

In other words – it depends.  😉

Dell Complicates Life for Home Businesses

I am fortunate in that I can run my business from my home.  I have a crack team of developers spread out all over the country and I can manage it all from here.  But working from home just got a little less convenient for guys like me.

A few months ago I ordered a new Dell Precision and had it delivered to a mailbox I rent for business use – I don’t want business mail intermingling with personal mail, and I definitely don’t want the UPS or FedEx truck coming through the neighborhood constantly.  Delivery was made and I was pleased.  I am a big fan of Dell.

Fast forward to a couple of weeks ago.  I ordered an additional LCD from Dell to replace the CRT I had been using as a second monitor.  Imagine my surprise when the Dell representative told me that they could not deliver to my mailbox address!  Only three short months ago, they had delivered an entire system just fine.  The fellow from Dell explained that there had been enough cases of fraud for the company to institute a policy of not shipping to mailbox addresses anymore unless the product was paid for in full at the time of order.  I was using my Dell Financial account, therefore I was told that they had to ship directly to my home.

Now, I can see the logic behind this – nobody likes to be stolen from, and it is only prudent to take steps to prevent it.  But if Dell truly will not ship to a mailbox address such as the UPS store, Kinko’s, etc. then I can think of a lot of home business operators who are going to be feeling the pinch.  What happens to home business operators who live in areas that have laws regarding the type and frequency of business deliveries that are allowed at one’s residence?  What happens to home business owners (like myself) who simply don’t want the FedEx or UPS truck rumbling up to their door?

I have a hard time getting mad at Dell for trying to protect themselves, but at the same time, I find myself thinking that this could be a huge PITA for many home business operators.

It is humorous to note that my LCD ended up being delivered to my mailbox anyway.  What’s the story, Dell?