Over the last few months, there’s been so much turmoil in the touchscreen tablet space! Consider:

1. HP’s newest foray into tablet computing, not with a Windows OS but instead with WebOS, subsequently gets beheaded in under 2 months after the TouchPad’s launch.
2. Android’s Honeycomb and Gingerbread tablets are growing in number, but not so much in market share.
3. RIM’s launch of the Playbook is widely acknowledged as a flop.
4. Apple’s iPad 2 launch in March is one of the most successful product launches in recent history.
5. And last but not least (by a slim margin), Microsoft continues to plug away with its Windows 7 stopgap strategy while working on Windows 8.

As a product person who’s been working on a HTML5-based offline web application, it’s been an exciting ride! So far, the recent events underscore several key ideas that product folks should take into account: platform flexibility, platform longevity, and control over the platform.Developing platform-specific applications will give you the broadest access to that platform’s advantages and features, but ties you into an ecosystem. Developing platform-neutral applications will give you the broadest access to a user base, but ties you into a variation of whack-a-mole. Given that a platform is composed of both hardware and software, product people have a set of issues to face which will shape your strategy. Hardware ends up being a snapshot in time, an end result of the evolutionary lessons and manufacturing capabilities up to a certain point. Unless a company directly controls their own hardware, it’s unable to fully understand and leverage all the nuances and potential of a device quickly. It takes time and exposure in a marketplace for both developers and consumers to achieve that knowledge. And in the case of hardware manufacturers themselves, failure is not so kind to a company and the ecosystem. In contrast, software is more malleable and can be adapted more easily. Your ability to deliver frequent iterations have less limitations to delivery.

The interesting development lately has to do with HTML5 apps versus native apps. While I’m a bit biased to one camp, I can say this: longevity aside, I’m interested in hitting the widest user base possible, and I’m willing to compromise slightly on performance and hardware features to gain an edge in control and reduce the friction it takes to get the user up and running. Not every company can say that, but every company needs to weigh those factors. And here’s the kicker: HTML5 is still an evolving spec. It is expected to get better over time, and build its API inventory up and continue cutting into the advantages that native apps have. As a wise man once said: “Choose wisely.”

I’m particularly interested in the product manager function both from an improve-my-everyday-work perspective as well as this-could-be-the-next-step-in-my-career point of view.  And what found today is this:

• Product Managers are the customer/are not the customer.
• Product Managers occupy a very interesting intersection between senior management, marketing, and development (mind you, this is biased towards my background in software development, YMMV when it comes to physical goods).
• Product Managers communicate a lot/do not communicate enough.

What do I do with this as a project manager in a Engineering organization (not a rhetorical question)?  More on this topic later!

I’ve personally seen demonstrations or used the following tools:

• ActionMethod
• Microsoft Project
• Danube Scrumworks
• Rally

but they all serve some subset of functionality that could be addressed by a better integrated and streamlined tool.  Consider the following scenarios:

• The project is starting up, and you’ve identified all of your stakeholders.  Where does someone set up resource assignments for WBS planning?  Where does someone set up mailing lists for the team?  Where does someone set up collaborative workspaces for documents and deliverables?
• The project is in flight, and a new resource has joined the team to assist with a new stream of work that arose because of scope changes.  Where does someone make assignment changes on the planned tasks?  How does someone get the person up to speed quickly with his/her respective peers?
• The project is closing down.  How does someone close a collaborative workspace, draft/issue a final status report, and archive deliverables with a minimum of effort?

In many cases, all of this work is distributed across physical machines, distinct programs, and perhaps even in analog form (as opposed to digital copies).  Managing projects to success should be about the project management, not the tool management.

Recommendation: Combine or integrate:

1. ad-hoc organizational modeling
2. sophisticated communications tools
3. work breakdown structures, and
4. collaborative workspaces and their deliverables

to foster a project-oriented work environment.  Has anyone seen such a beast?