[teampractices] MVP or MMP?

[David Strine]

These scales are used when UX, art style and usability are major focuses.
These are qualitative goals. You're right, projects are never done. These
targets help teams set qualitative goals and quality bars.

I can't relay the specific implementations from other companies and I left
out one key idea for brevity. When a team implements these scales, they
reference past features or products. You might have 2 or 3 examples of
prototype, one or two MVPs and a single, really good BATMAN.

Referring to order of development, yes, BATMAN features are the big
innovative ideas. The done-ness states don't necessarily relate to when you
do something or how your org is structured. Innovative features aren't
always the last things to be done. Teams can be split off to do skunkworks
sort of R&D.

I would totally be down to do a brownbag on how these are used in other
companies.


On Tue, Jun 16, 2015 at 2:14 PM, Kevin Smith <ksmith at wikimedia.org> wrote:

>
> On Mon, Jun 15, 2015 at 10:14 AM, David Strine <dstrine at wikimedia.org>
> wrote:
>
>> Is the current usage of MVP in context with other levels of "done"?
>>
>
>>    - MVP - truly MVP, barely consumable by users
>>    - Competitive - meets or slightly exceeds competitors
>>    - BATMAN  - yes, all caps. this should be so cool it makes your head
>>    explode!
>>
>>
>>
>>    - MVP - truly MVP, barely consumable by users
>>    - MCP - Minimum Competitive Product
>>
>> I'm having all kinds of trouble reacting to this. So rather than
> attempting to assemble a coherent flowing reply, I'll offer bullet point
> thoughts:
>
>    - To me, "done" refers to a task or feature, not to a product. A
>    product is never done.
>    - I also tend to use MVP much more in relation to specific features
>    (splitting a feature into core functionality vs. bells and whistles), and I
>    have used it less in a product context (which major features to include and
>    which to leave out).
>    - MVP is much more interesting to me than MCP, because MVP allows us
>    to find out what our customers really want, instead of us guessing (and
>    coming up with our MCP).
>    - Ideally, MVP should provide "most" of the MCP value, while costing
>    "substantially" less. Within a single feature, I suspect that often MVP
>    provides 80% of the MCP value at 20% of the MCP cost. That's unlikely to be
>    true at a product level, but even then, perhaps it is.
>    - My guess would be that many BATMAN experiences happen when a team
>    chooses an innovative path, and thus would be work done *instead of* MCP,
>    rather than being done in addition to it.
>
> Thanks for asking that question. Interesting stuff to ponder.
>
> Kevin
>
> _______________________________________________
> teampractices mailing list
> teampractices at lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/teampractices
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.wikimedia.org/pipermail/teampractices/attachments/20150617/eb76ae3f/attachment.html>