Getting Ready for v1.0
It has been way too long since my last post.
OK, so what have I been doing that’s kept me from writing my, usually way too long, posts? Well, my day job of course. But, with that being said, what’s this about?
Since I’ve been dealing a lot lately with getting new products out the door - both including brand new, and major revs to those that currently exist (v1.0 to v2.0 update type stuff), I wanted to write a little bit about paring down feature sets.
There’s a major temptation to fulfill and match-up to terms like, “compelling” and “value-add” - especially for v1.0. Everyone is excited and wants to see their efforts make an impact on the company.
The most important thing to not overlook is actually getting something out the door. Keep it as simple as possible.
That’s why defining your market & your product up-front is so important. It drives you to make decisions. Acting as the voice of the customer, PM’s out there (who are more than likely driving requirements) must be able to say, “no, not v1.0.”
Each and every requirement adds time to your go-to-market. Are you sure that each one of those is necessary for a solid v1.0 launch that your target market is going to want to use?
Remember, products typically don’t start to really come into their own until shipping the second / third revs. In today’s world - Web apps and software alike, there is nothing holding any PM back from turning around weekly revisions.
That being said, QA cycles are extremely important, but I’ll leave that aside for now.
Get something out the door. If you haven’t shipped something in 3-4 months, that’s a problem. Figure out what the roadblocks are, and focus.
Yes, feedback is 100% critical. But draw the line and commit. You can’t keep tweaking requirements during your v1.0 dev cycle unless you are absolutely sure you have just plain missed something that’s valuable to your market. Products can fail because they are just simply not compelling.
But there comes a time when you MUST commit, and believe that what you have locked in is going to rock. This lands in agile territory to a degree. Locking in to a sprint / iteration, and not changing it until it’s done and released.
Same goes for v1.0. There is a high temptation to listen to everyone, because nothing is yet out in the market. Yes, listen. But do more logging than listening, especially if you have what you feel is a well-crafted product definition and requirements that are tied to that definition.
Everyone will always want to add everything. That’s why PMs must always be stripping things down to their core for the customer / user - especially during those critical months / weeks leading up to putting v1.0 out to market.
