With all due respect to Seth Godin, while he may be a marketing guru, his post about minimum viable product makes me think that he hasn’t participated in the product development process in a very long time, considering that his definition of minimum viable product is pretty coarse (and likely why it doesn’t work!).
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!
Over the last few months, there’s been so much turmoil in the touchscreen tablet space! Consider:
- 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.
- Android’s Honeycomb and Gingerbread tablets are growing in number, but not so much in market share.
- RIM’s launch of the Playbook is widely acknowledged as a flop.
- Apple’s iPad 2 launch in March is one of the most successful product launches in recent history.
- 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. Continue reading
So last night, I had the opportunity to see Ken Schwaber in action at the AgileNYC event in LimeWire’s Tribeca offices with a friend of mine. It was a great event with a lot of people ranging widely in their exposure to Scrum. I find that there’s always a particular nuance that I relearn when I attend these talks, and the key one that stuck was all about how to plan and execute towards the goal of “Done Done”. Read on to find out more!
Scrum and agile (note the lowercase!) development techniques have been around for a few years now, and prominent companies use it in some form or another. However, I’ve seen multiple instances where clients and management alike will derail the whole notion of Scrum! It pains me to see it, so here’s a Part 1 (of many more to come) to help convince skeptics that Scrum can be good for you (just like apples!). This post will focus on a common concern I’ve heard: “Scrum seems nice and all, but how do we manage budgets?”
Twitter and Foursquare are two easy examples that come to mind for services that have failed very publicly. They get pretty bad press from people because of service outages. I myself have been on the receiving end too, but as someone who’s been in the application development side of the house, I know that these experiences are invaluable. There’s nothing like a few million users screaming at you, that’s for sure!
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.
The other day, I was preparing a quickie assessment of the biggest office suppliers in the US, and I thought “Instead of trying Google or Wikipedia, I’ll use this newfangled Wolfram Alpha thingy that’s out now.” And after approaching that query, along with some other spur-of-the-moment questions, I’ve finally realized what Wolfram Alpha is.
When it comes to the classic “iron triangle” project management model of time, scope, and cost, the three key stakeholder groups which directly influence and work on a typical interactive project are in constant conflict based on their perspectives. I’ve been asked many times in the past: “What’s your approach to handling this kind of situation? How do you resolve the differences between the creative, business, and technical teams?”
Software development lifecycle processes can sometimes be seen as impediments or tedious tasks. But it is worth reminding everyone that the smart work up front will save you headaches later. In my experience, well-written software requirements serve two main purposes: it orients all project participants and helps get buy-in about what you’re trying to do (since you’re articulating what you’re trying to accomplish), and it makes sure that everyone (from the project sponsor(s) down to the technologist and back up to the end user) can say that the project is done to expectations.
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.