Believe me, killing your own product is the most painful task you can ever be "told" to do. Sometimes, we are in so much love with what we build, that we tend to forget the ecosystem around it. This could be a BLUNDER for any product manager.
First line of a PM's job description surely reads - "Define the right product to build". And when this definition is changed in such a drastic way that closing current development makes more sense, more often than not, teams start to get frustrated and fidgety. What others may not understand (and the PM must) is that "being in business" is more important and critical than being on the cutting edge of technology or building beautiful products.
For a team, to collectively enter the comfortable "I-know-enough" zone is pretty common. I have seen some products getting closed / realigned so late and with such convincing reasons that at times I start to wonder why not earlier! Things could get tricky when there is a trade-off between making early decisions and minimizing risks. How to handle this is not just a strategic stunt but also a challenge for PMs.
So what could be the reasons that could lead to shelving of products?
1. Technological imbalance:
Could be caused by inventions, acquisitions, and even by slow development progress.
2. Organization wide priority shuffle.
Tying your product with the mainstream value chain of your business is crucial. And with every
adjustment in this chain, products' priorities are often realigned.
3. Turbulence in the ecosystem
What do you do when you find out that your potential customers will not be in business by the time you are ready to ship? Stop. Think.
What do you do when you find out that your competitors are marching at a velocity that is several times yours? Think. Stop.
and last but not the least
4. Dearth of dollars!
Sponsor(s) could lose the confidence or money and may pull out.
Do you know of more reasons?
And yes, my big question is still open - should you "love" your product?
If you are starting on some new project, and your role needs you to define and prioritize requirements for a product, taking the "Breadth-First Approach" makes a lot of sense.
1. Who are we doing this for? Look for proper nouns.
2. Which two main problems will our system solve?
3. Who is paying for this?
4. What is the release schedule?
5. What are the risks (as of now) and external dependencies?
6. Is someone else also doing similar work? (inside or outside your organization)
If the project is already underway, you may want to look at some inception stage sketches. If the project however is relatively young, you should draw those yourself. At some point, this effort must incorporate some kind of a conceptual domain model.
The next thing that you must think about is how would agile methodology scale to adjust with your team and the size of your product. And no one at any stage shall forget that along with the promise of delivering value pretty early, agile processes are also designed for the team to learn how to deliver value more effectively and efficiently.
Lastly, if you are much involved in capturing requirements or selling the product, you should always start to prepare (and even rehearse) your elevator pitch. You must have crystal clear, and unambiguous answers for: who you are, what you do, and why you do it better.
And finally today, I leave you with a quote that quite well summarizes the entire agile philosophy:
It’s never the size of the step that a person takes that counts, but its direction.
--Narrative Means to Therapeutic Ends, Michael White & David Epston
If you have to show-off a new cool feature to customers without having them to download or install stuff, do a screencast.
If you need to popularize a new tool that you are using and find useful, do a screencast.
If you just prepared a new mock-up and wish to communicate it and it's purpose to your team, without collecting all of them in a room, do a screencast.
If you have a new slide-set that you'd want the readers to 'understand' and not just 'read', do a screencast.
If you wish to teach others on how to install, configure and use your product, without asking them to read through the lengthy manual, do a screencast.
In any successful project, intra-team communication is of utmost importance. And when you have globally distributed teams with time differences, it is more suitable at times to do a screencast and convey your point rather than wait for mutual free slots and discuss over telecon.
Often, putting across tutorials or new ideas in video attracts more and wider attention. And yes, voice narration is a certain cure for ambiguity.
One of the best tools in the market for producing screencasts is Camtasia Studio. A complete list of tools is here.
And here are some examples of good screencasting.
I attended the "Certified Scrum Product Owner" course at Helsinki last month. Kenny Rubin was the trainer. He gave some very useful insights to the group about what exactly is the role of a PO in an agile project. There were some lively and interesting discussions going on the room for those two days.
Here are a few key points that I felt worth noting in my notebook during that course:
* Good product owners generally hate "work in progress".
* Real and active product owners 'must' see and approve the sprint content / demo before sprint review.
* User stories are not contracts.
* 'Definition of done' for user stories may get modified as result of interim demos.
* Product owner is not a tester. He should be presented only functionally tested stuff. He then may do user acceptance testing.
* Product owner's boss can not change the priorities in the product backlog! He may add requirements though.
* If a product owner plans for extensive documentation, he must also keep in mind that he is responsible to maintain it.
Last but not certainly the least:
* A good product owner should always "be there" for his team.
Finally, I leave you with the opening lines of Kenny while he was giving us the traditional introduction about "Why Agile?"
"...Let's assume we are a team, assembled here on day-one to kick off a brand new, huge project. In future will there be any other day when we'll know any lesser about this project than what we know today? Now, when do you think we should make all the crucial decisions?..."
