Sunday, July 27, 2008

The king is dead...long live the king?

I finally start blogging (somewhat) seriously this month and look what happens - one of the (supposedly) biggest names on the blogosphere "retires".

This could be the "Death of the A-list bloggers" or it could be a complete and utter hoax.

I just think that he just got scared that I was going to take over! ;-)

To kindle or not...

I have been flip-flopping on buying a Kindle (ostensibly for the wife...). So I figured I would write my thoughts down.

On the one hand the the positives seem to be
1. Save paper
2. Access to newspapers
3. Quick and easy wireless download
4. Ability to quickly reference stuff on Wikipedia!!
5. Ability to view free books from multiple locations (though I need to dig more into formats supported)
5. a. Support for multiple file formats (Supposedly can use MobiPocket Creator for HTML, MS Word, Text, PDF, etc) means I can transfer many of my docs over to the kindle and read them there rather than my laptop!
6. Good battery life (because it isn't backlit?)
7. Music and audiobook support (time to use all those books I bought from Audible)
8. Heard good things about usability - buying, search, page flip etc (need to buy and validate)
9. Size(again, need to buy?)
10. Shared library (err... assuming I steal my wife's kindle all the time)
11. Free first chapter (seems like a good idea)

1. No image support
2. Charges for RSS Support - whats up with charging for free content? I understand about wireless costs, but at least provide the option to sync locally via USB!
3. Can't buy books at half price any more? That sucks

Hmmm... Who am I kidding? This might be a no-brainer!
Oh wait...
4. $359 (I am cheap...)

So, it looks like all the negatives are monetary - and they really aren't too bad! I think it is time to get one!

I don't think that this news -
( makes a difference. Nothing worth waiting for from the looks of it...

Some other thoughts -
- I don't buy the idea of using your smartphone (WM or iPhone whatever) to read books. The screen is simply too small for sustained reading.

- I also have to admire the business plan where Amazon gets to tie you in by providing a complete ecosystem for buying and reading books (iTunes anyone?).

- I think that Amazon will do well to take advantage of the fact that they have a device that is used for viewing information and provide an add-on package for browsing data. ie, paid internet access.
- At that point, support for WiFi will become important too...
- At that point they _really_ have to provide free access to blogs.

Update :
Bought it, and it is a big hit with the wife!
- The screen is really cool. Not being backlit makes a difference!
- The process of buying books and reading them is really easy. Amazon got that right.
- I didn't realize that you can also use it to browse the web. Basic browser.
- Tried a couple of file conversions (pdf to .lit) and it worked pretty good.

I might have to buy one for myself too!

Agile Product Management

This was a great post, so am pasting this word to word :

Source :

Agile Product Management - The Rosetta Stone

What should you do differently to become an Agile Product Manager? Not much, as it turns out -- but you may do some things more frequently than you’re used to. Let’s take a look at how Agile development methodologies impact the five main areas of Product Management: Planning, Building, Launching, Maintaining, and Retirement.

Overall, the organization still needs good methods, such as Robert Cooper’s Stage-Gate™, to help prioritize product ideas and projects. Agile methods promise to deliver higher productivity for the same cost, but you still need to choose the projects with the best strategic fit.

The planning cycle includes building a business case, determining a market and product strategy, positioning the product for success, and setting a long-term product roadmap. To create these deliverables, you’ll still need to do a thorough market analysis. Can you do it in an “agile” way? It depends on your organization’s tolerance for risk, and the size of the project. Some organizations can move forward on smaller projects and do their analysis in parallel. For larger investments, most organizations want to have a more complete picture of the opportunity before they start development.

As you complete your analysis, the deliverables you create may be labeled differently in an Agile organization. What we think of as product positioning, Agile teams call their “vision.” Your near-term roadmap becomes a “release plan.” And “sprint plans” may roll up into a Product Plan that details how the organization will execute on the next market release.

Along the way, you’ll begin collecting requirements and tracking them in an Agile backlog. Today you probably refer to that as your “enhancement list.” Individual requirements get written as “user stories,” which put the requirements in context. You’ll still need to gather non-functional requirements; you’ll still need to prioritize; and you’ll still negotiate what’s in each sprint. You’ll still supply some product specifications, in the form of acceptance criteria.

But what we really like about Agile is that it embodies what we’ve taught for the last nine years – that a good requirements process is collaborative. What’s hard for Agile Product Managers, and for Agile developers too, is to trust this new collaborative process. To not write every single detail down in advance and then toss it back and forth across the wall – but instead, to write some user stories and then talk about them. Together. At the same time, preferably face to face. Every day!

That’s the real revolution of Agile – not the two-to-four week sprints, not pair programming or test driven development (TDD) – but the conversation between the people who hold the product vision and the people who are executing on the product vision. The revolution of trust within the team – no more finger-pointing, no more scape-goating.

(Here’s a secret: Any development methodology can be successful when this collaboration and trust exist between Development and Product Management!)

Product Launch
So in Agile, you won’t know exactly which features will make the release until just a few weeks before the release. Doesn’t that pose some problems for getting launch collateral ready? Come on… get real. You don’t know that information with much certainty today!

With Agile, you’ll likely know with greater certainty which features are really finished and ready for release, because they were completed in a prior sprint. All that remains is the functionality included in the final sprint, and as each story is completed, you can make sure it’s included in the collateral.

The potential exists for functionality to be released to users in smaller chunks. Marketing communication strategies need to be discussed early in the planning process to take into account potential interim releases and their impact on the competitive landscape, customer adoption, and market timing.

The real change is that the Development team may need to get used to the product “sitting on the shelf” after it’s complete, so that Marketing can time the release for the greatest impact, and adequately prepare the market, the users, and the sales teams for the launch.

This phase comes in two flavors: maintenance on the product itself and, in commercial software, sustaining marketing activities over the life cycle of the product.

Product maintenance is simply another pass at the backlog. But, just like today, there needs to be resource allocated to emergency bug-fixing, and enhancement projects must be authorized from a business perspective.

Sustaining marketing continues to be part of the Product Manager’s or Product Marketer’s role, to whatever extent it is today. Agile development doesn’t have a lot of impact here, but we can learn from the Agile process and apply it to how we develop, field, and test our marketing programs. (More on this in a future newsletter.)

You still need to create the business case for removing a product from the market. Agile methodologies can’t impact this directly. But if the Agile team’s job is done well over the lifetime of the product, you may find that fewer products need to be taken off the market due to lack of sales. The successful ones should last longer in the marketplace because the team can be more responsive to market needs and changes.

In summary, the tasks that product managers do over the lifecycle of the product don’t change. Their name, form, or frequency may change, but executives still need the same solid data on which to make good business decisions, and it still takes a collaborative team (product management, marketing, sales, support, and development) to produce great products.

Friday, July 18, 2008

The Power of Google ads!

This is a little mean, but take a look at the advertisements that came up on this story on Khloe Kardashian. How on earth did they focus on teeth (yellow or not) and weight?
The ads are "She has yellow teeth", "Lose 15 pounds" "2008 diet of the year"

Tuesday, July 1, 2008


Probably the best image viewer - and the most innovative UI representation I have seen! Completely changed the way I imagined images could be viewed.