As a product guy, minimum viable product is one important method with which to organize product development efforts, and to maximize the amount of benefit derived from scarce engineering, development, and management resources. In agile development circles, Product Owners work with the team to consciously choose to release “MVPs” frequently, or release a bunch of them together in an integrated package or manner. My take is that “minimum viable product” is the set of features that satisfy the core needs of your target champion audience and provides the team with the greatest return in both actionable feedback and revenue/revenue potential. More than one can go live at a time!

To work backwards a little, agile development and Scrum in particular derive big benefits from thinking in this manner. The reason being that minimum viable product first forces you to think about a set of features, functionality, and fixes that make sense together, and offer your users the greatest benefit. Then, once you arrange things into a bundle, you look for areas where it’s possible to make them bite-sized for the team to work with and to execute on. Let’s say that you end up with 3 minimal viable “products”; that may simply correlate to three distinct milestone dates throughout a calendar year. But not all of them have to go to market immediately, not all of them have to be released as soon as they’re individually done!

Oftentimes, the driving force for product people to tie one minimum viable product to a release is the urge to get something to market ASAP. I say that you ought to resist that urge with all your might! It’s not about the “smallest kernel of your core idea” but rather, how you help your team build a great product iteration that goes to market successfully. It is up to the product folks to exercise some discipline and patience about what exactly constitutes minimum viable product. Anticipating how your users will be delighted by a single button versus a single experience makes all the difference in the world.

In conclusion, for all you product folks out there: Minimum viable product is the set of features that satisfy the core needs of your target champion audience and provides the team with the greatest return in both actionable feedback and revenue/revenue potential. Bundle multiple MVPs if you think the whole is greater than the sum of its parts.

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.”

For those of you who could use a refresher, “Done Done” is based on knowing that a work item is capable of passing a set of agreed-to criteria between the stakeholders as well being capable of launching the very same work item into production. It was refreshing to hear a reference to the basic project management tenet, the Iron Triangle, and the concept of altering schedules/time (e.g. the Sprint length) to improve quality. Essentially, the common issue occurs when one person’s definition of done often doesn’t match someone else’s definition of done. When you can check off Done Done with everyone, that’s when you know you’re golden!

So at the end of the talk, I went up to Ken and asked: “What if you have the Product Owner/Manager constantly changing their requirements and definition-of-done-s on you in a start-up kind of environment?” To paraphrase, his response was clear and simple: it is what it is. The fault lies in both camps: on the team’s side, the PO isn’t being responsible by sticking to a clear-enough definition of done, and the team/ScrumMaster isn’t demanding a clear-enough definition in the first place. Both sides need to work something out, or else something or someone will break.

At the end of the day, you need to have clear requirements/user stories that also have clear (and preferably specific!) definitions of done (think acceptance criteria, functional/integration/unit tests, documentation, qualifying against industry standards, etc.). It also helps to have an overarching Sprint objective and Sprint-oriented definition of done. It’s the only way to get good expectation management and ultimately, good software. So slow down, talk it out, and get then it done!

The thing is, teams are human and make mistakes. It’s easy for a team to fracture or start pointing fingers at each other; it’s much harder for the team to hold together, either collectively or with the help of a good manager. And once you’ve been through one ordeal and you pull through successfully, that trust and mutual respect go a heck of a long way. So the next time you have your own fail whale with a team, take a deep breath, scramble to fix the problem and the perception, and then have a strong drink with everyone. You’ve earned it.

Wolfram Alpha is a great way to find a fact and do some analysis about it. You might think that after 19 days of being available to the public that I would understand what it’s all about as a user. Just like Mathematica, I think this product is a tad ahead of its time. This quote from their site: “Wolfram|Alpha’s long-term goal is to make all systematic knowledge immediately computable and accessible to everyone” is now much more meaningful after having used the service: “immediately computable” means a whole world of analysis can be at your fingertips, and “systematic knowledge” is another phrase for data and facts.

Now, there are some recognized shortcomings but by-and-large, as a proof-of-concept, it’s fantastic! The above link should bring you to a query state that lists the following major US specialty retailers: Staples, Office Depot, and OfficeMax. Now what I was trying to do was to find information quickly about this particular sector of retailers, provide a basis to generate an estimate on the size of the market for office supplies, and see data points relative to each other. And of course, it did so beautifully.

There’s plenty more work to follow, however. I think there are two key high-priority enhancement projects Wolfram Alpha should consider for their next release cycle:

1. a simplified and standardized (mathematical?) grammar structure, and
2. a fact-drilling capability.

The first suggestion would greatly help users understand how to structure their input and reduce the incidence of the “don’t know how to handle the input” page appearing to users. After all, I can’t think of a single language that doesn’t have syntax with which to standardize expressions and context. And at the same time, I don’t think one system can understand every single kind of expression and context from a myraid of users without extensive effort into a (in my opinion) futile effort.

The second suggestion would be a means to offer transparency to the facts presented by the engine. Similar to Wikipedia and to the tradition of citations in written works, Wolfram Alpha should consider a way to cite every single fact in its database. After all, each one should be verifiable in its own way, and the source content would go a long ways to confirming that work. Good luck to the Wolfram Alpha team, I wish you the best of success!

Recommendations: Put in a grammar/syntax structure to help users understand how to input their queries, while keeping it at a minimum. And don’t forget the beauty of the Web being built on hyperlinks, so link to your facts where possible!

My perspective comes from lots of hands-on experience with each of the three groups. Creative folks need time to let ideas marinate and mature into thoughtful assets. Technical folks (good ones, anyway) need scope to build the best possible product (if only I had a dime for every time a developer’s asked me “Well, if I do it this way it can work okay, but I think it’s better to do it this way because [insert comment about future capabilities or cool functionality]“, I’d be rich!). And of course, we can’t forget business folks, whose tolerance for time seem to fall lower every day. How can you get the three groups working together?

Recommendation: Building mutual respect and condensing each group’s issues into soundbites for the other groups is my approach to handling any initial situation. Project managers must have a strong curiosity for new domains and the nuances of each group’s work and background, which will help them argue for each side. This kind of position will guide a project to success for all stakeholders since it strikes a good balance and effectively negotiates a lot of tension out of the situation. However, when I’m in between a rock and a hard place, I have to side with the money but not without a fight for quality and extensibility. Doing right by the client is my mantra and I would never sacrifice that until I’m kicked out of the building.

What do you think?

The trick is how to write a good requirement, for any number of situations. Part of the answer is to follow this convention:

The [your words here: system, actor, function, dependency, etc.]
must [your words here: do, process, store, etc.]
to [your words here: accomplish a goal, serve a purpose, etc.].

and to focus on the “what” (substance) of the need as opposed to the “how” (design) of the need. In addition, there are 8 key criteria that each requirement should satisfy to be considered well written.

As a business analyst, you should think about addressing the following points to evaluate how well written the requirement is:

• Necessity €“ A “must have”. Conversely, it helps to avoid gold-plating and gives you a prioritization tool during the build phase of work.
• Unambiguous-ness €“ Use assertive words without vague terms. This also helps the writer/stakeholder focus on the “what” of the product/service/result as opposed to the “how” and proactively reducing interpretation issues.
• Testability €“ Can be verified by inspection, analysis, or demonstration, which means that there’s a qualifying attribute to almost everything based on the idea that you know it when you see it.
• Conciseness €“ Conveys what is required and is easy to read yet. If you end up writing a page-long requirement, it’s time to make it more atomic.
• Consistency €“ Does not contradict other requirements and uses a known vocabulary that should be defined for the layman (or at least the wider group).
• Completeness €“ Does not require you to look at additional text to know what the requirement means. At the same time, requirements may be related to each other, which then requires the writer to add a separate requirement that talks about interaction between multiple requirements.
• Feasibility €“ A requirement that can be implemented. Typically, time is a factor, but cost and available resources will all ultimately play a role in what you deem feasible or realistic.
• Traceability €“ Has a unique identifier and is tracked through the development of the product/service/result. Along with testability, this attribute plays a role in ensuring that things do not get lost in the cracks.

The above list was adapted from here based on my own experience, and there is a wealth of material on the Web and in print that follows these conventions (or their spirit). Unfortunately, despite the volumes dedicated to this topic, it still frustrates users and is a task that is taken lightly because it is time spent with seemingly less tangible benefit up front. I have had many experiences where the team will ask “What did (insert name) mean when he/she wrote this,” which resulted in time wasted, potentially incorrect coding to occur, and costly testing time and effort down the line that reveals something “wrong” with the system but is hard to define or pin down.

Recommendation: Do the work upfront, and you’ll save time and headache later. As a business stakeholder, focus on the “what”, and allow technical subject matter experts worry about the “how” (which they are supposed to do anyway). Well-written requirements based on necessity, unambiguousness, testability, conciseness, consistency, completeness, feasibility, and traceability will save the day.