Shipping the v1.0
While the indigestion and heartburn hasn’t completely gone away yet, and probably won’t until we roll through our first update to the product, we have gone live (read: not fully launched with all the Marketing excitement behind the release) with a milestone product release for our company.
It feels damn good, but also a little daunting.
10 products in the portfolio, and the majority of them are going through mid-large type revisions, or are still in the v1.0 cycle.
I have my eye both on building out roadmaps, cross-product integration, listening / gathering market feedback, but also not getting too attached. We’re going to have to EOL something in the future, so treating a product like your new cute fuzzy little puppy may in fact not serve you too well.
Also, quick thanks to Scott and Roger for their support & feedback. Having contacts and friends in the same position as you to be able to call on for advice and guidance makes all the difference in the World.
I may in fact have time to blog some more….hopefully.
Pushing 1.0 Out the Door
I’m certainly going to have a lot more to say now that we are 1 day away from pushing out a brand new v1.0 product out the door. I will say this for now:
- E-commerce integration rarely go as expected
- Trust your instincts
- Trust the people around you, pushing for the same goal
- Do what you feel is right
As I said, more on the topic later, but I find v1.0 efforts fascinating for how different they are from other releases and definitely want to write more on the topic.
Go-Live or Launch
When you have a new product (or a “v1.0″ as I like to say) you have the opportunity to do both a go-live (or as some folks call it - a “soft launch”) and a full-on, hardcore, big court press marketing / sales effort launch.
There is a big difference between the two and what they provide to you in strategic benefit.
For me, as PM, the biggest thing they offer is flexibility in risk mitigation. If you go-live and launch all on the same day, chances are you’re going to have some very unhappy customers and users looking for retribution with pitch forks and fire. Eek. Avoid that at all costs if you can.
We’ve got a 2 week window baked into the marketing / launch plan. You have to be able to offer up a chunk of time to things just flat-out going wrong. For example, if you were to do a full-on press release, big ad splashes in a bunch of places (and more) and then you realize that while you were successful in driving 5,000 people to try & subscribe, the product just cacked?
Bad news bears.
In the end, ensure you always leave some time. And, depending on the size of a major release (i.e., a v1.0 to a v2.0), you may also want to think about doing the same thing — this doesn’t only have to apply to v1.0’s.
Some Agile Development Commentary
I’ve written several posts in the past regarding agile development and how we’re leveraging some of it’s benefits internally at the present time. There is a solid post up at Tyner Blain, in which Scott provides some good feedback on a post written by fellow blogger Mishkin Berteig.
There’s a story a friend of mine (who works within a very large organization as a project manager) shared with me a while back. He was sitting in a meeting with a client and his top project team. A piece of QA within the release process for their code had broken down their process, preventing them from essentially, getting shit done.
That’s generally bad.
My good friend recognized something very critical though - why was backend regression testing (the piece of QA in question) occurring for the UX component of the software? They had nothing to do with one another, but were on the schedule and continued to be done.
The response from those around the table was basically, “that’s just how we do things.” Yikes! That answer, right there, can sum up a lot of what’s wrong within long, severely drawn-out release cycles.
We’re trying to get a v1.0 out the door, and will probably end up doing so this week. Now, we’ve been working on this (from the ground up) for the last, say, 2 1/2 months. That’s an incredibly short period of time to a) define a product b) get it through a development cycle c) market it, and d) release it. If, at any time, my response to a question had been, “that’s just the way it’s done” and thus prevented us from completing a key piece of the PDLC faster, I’d have expected I’d be fired partway through the process.
These types of excuses can be directly tied back to a few things:
- Egos - people want to cover their own asses
- Straight-up stupidity and fear - people don’t understand their role / job and are afraid to say, “I don’t know”
- Fear imposed by higher-ups - VPs and directors with no clue and way too much leeway to say, “my way or the high way”
- Silo’d, non product-centric organizations - those that define the company around roles instead of products
That last one is very important and one I remember touching on before. Agility isn’t just about having senior-level developers you can trust with flexible requirements, but it’s about everyone caring and contributing to the products themselves.
Who cares if someone is “in marketing” or “in legal?” Why does that matter? Their sole function is to solve pain for your customers and build great product. That’s why it’s so critical to commit to product management and not make it a half-assed effort just because everyone else is doing it. Get them in the center to do what they do - ensure the planning is place and crap makes sense, and then execute.
I digressed quite a bit, and it’s got nothing to do with how Scott’s post is written. The difference between using waterfall and using agile approaches is very simple - at least in my mind. If you have a complex, workflow-intensive product (like a banking or insurance-level application), you should be planning your PDLC’s using waterfall methods. If not, plan your whole PDLC using agile. No question.
Of course, that’s not to say, product groups within the overall (probably silo’d) organization that make up the individual feature teams or “product” teams if your suite is broken down that way (a la Microsoft) can’t use agile. They should. It would probably help them work faster and more closely together.
Sorry, Scott — I started out by intending to respond to some of your key points, but kinda got off on a tangent.
Releases with QA
My release cycle does not include a serial QA pass. What I mean is, I don’t block out 1-2 weeks after a “code freeze” to do QA; I want QA being done while the developer’s mind is still fresh on the code and they haven’t already moved on to something else.
A typical release cycle for me will see a QA lead create a test plan for what’s going out the door, and then work with the developer (or dev lead on the project) to cycle through any found defects. The QA test plan is captured directly from our defect tracking system, which is where I log all requirements for a release.
This helps us in a couple of ways. The first being, no one is sitting around waiting for QA to sign-off on a release. The second is development & QA are directly engaged, and talking about the release so defects can be fixed faster. There’s no cycle time between when QA ends and when fixing any bugs they have found begins.
I’d always recommend looking at what happens when you encounter a code freeze in your release cycle. Are you doing all that you can to ensure the process of getting high-quality product shipped as fast as possible?
