“Minimal market features” is short-hand for describing the product that is just barely good enough to go to market.

Depending on your strategy, “good enough” may mean “technically capable of solving the problem” or may mean “a joy to use, when solving the problem.” Also – depending on your strategy, you may need to solve one or more problems; and you may need to solve them for one or more personas or market segments.

The idea is that you don’t delay the release of your product until you have built something that solves every problem for every customer in every market segment. Figure out something that someone will buy, and get that into the market as soon as possible, then do incremental updates to make the product better.

Does that help?

Thanks for mentioning minimal market features in your comment, it reminded me that this article on satisficing is closely related to the one I just wrote on minimum market acceptance: http://tynerblain.com/blog/2010/03/31/minimum-market-acceptance/

I haven’t worked on any projects where the requirements are truly static. Even something in the scientific domain, where isolating variables and controlling (repeatable) procedures may result in “static” operational requirements can still be dynamic. Consider the potential value of finding novel ways to slice and dice the resulting data. When I was still doing engineering work, many times when running experiments, my goal was find insights into behavior and trends, and reviewing the data would often lead me to want to review the data in unanticipated ways.

Your point about real-world feedback is spot on!

The funny thing is, in old waterfall projects, that same never-ending list continues to grow, it just either isn’t acknowledged, or isn’t shared, for risk of derailing the project.

I always visualize a kid sticking his fingers in his ears and shouting “blah blah blah, I can’t hear you! I’m not listening!” As if by ignoring new information about your market, it somehow doesn’t exist.

I love how you’ve approached this as relationship development, where it happens to evolve from the creation of software. It becomes collaboration, where one of the mechanisms is delivering software.

It also helps to remember that we “value communication over…” and that we do work for the business because the value the business places on what we create exceeds the cost of creation. Keeping those in mind, and building on a relationship of trust – just good thinking.

Thanks!

When is good enough? Good enough is when the pain is not mitigated by the provided value, and the company has established themselves as an upright place of not only good intentions, but good continual results to continue to grow on that product foundation as well as community support (customers, third party developers, partners, etc).

This takes time to evolve – but this foundation, like in any relationship, equates to one solidly backed by trust I believe. Customers trust that you are there for them, to solve their problems, to deliver, in short term and long term, and vendors’ desire to continue giving back, gaining and building that loyal customer following.

With these “true blue” product intentions, iterative development is possible.

If thought in this light, building SW is not much different than building human relationships.

With open and telling media outlets (blogs), this is a beautiful silver-lining of social media. Integrity is being brought back into he product schema – and PMs can ack that and work it to their advantage if they know how – with both a short and long term strategy.