MVP, "Mighty" or "Minimum"?

Codidact Platform Ideas
1

We’re designing a mighty fat system right now. Yet we’re calling it MVP. Building MVPs regularly at work my observation is that our M currently stands for mighty not minimum.

It’s mostly an endless list of wishes and feature request that were ignored on SE.

We’re currently talking about features that SE didn’t implement until years after launch and call them MVP relevant. I’m a moderator on a small site and there are discussions and assumptions about features necessary for launch which I haven’t even touched on SE more than a handful of times — if ever. We don’t need those now — maybe never.

Every feature we have in our Mighty Viable Product moves the launch date back.

If you’re not embarrassed by the first version of your product, you’ve launched too late - Reid Hoffman

Minimum viable products by nature try to do three things

  1. be a product
  2. be viable
  3. and above all else being out there as fast as possible by being minimal.

In my observation we’re bad-ish at 1) and honestly horrible at 3).

Why bad-ish at being a product?

  • We don’t know if we want to
    1. launch a Q&A community with our own SW which happens to be open source or
    2. build an open source Q&A SW which we also happen to host once ourselves.
  • Those are two hugely different things from a product perspective but that should be discussed in another thread.

Why horrible on being minimum?

We are apparently (subconsciously) planning for the full scope of SE on day one, even though we have hard data that we don’t need that.

Example Flagging: Over the project we have literally dozens of SE moderators who have access to all sorts of data about number of flags on sites of various sizes telling us how many flags we can expect in the beginning.

We can verify over several communities, but it will be around 1-2 a day. Max.
We don’t need a bunch of flag types users with a certain trust level validating flags and whatnot.

We very wisely said DCMA & GDPR requests are handled manually in the beginning.
Let’s do the same for flags.

Let’s design the MVP for that.

Flags

  • Users can flag posts and comments.
  • Moderators have a list of active flags and a way to mark them cleared.

That’s it. That’s the flagging MVP.

That way we just shaved a week of our launch roadmap.

If we do that for the rest we’ll be live for Easter — if not, Christmas.

Disclaimer regarding the example: The summary is “fine” it’s the way we handle all MVP features here. I had to pick one. I’m questioning our current modus operandi not this specific summary.

Editing / Flagging / Closing Example

Editing

All posts that are not locked (locks are not MVP) can be edited.

Authors can edit freely. Users with the appropriate trust level can edit freely. Users below that trust level can suggest edits.

All edits use the same affordance (“edit” link or whatever) and interface, except that users who cannot edit directly are told the edit will be reviewed before starting and get a notification of pending review on submission.

The author of a post receives a notification of a pending or direct edit.

If there is a pending edit on a post, the post shows an indication of this fact. Users with the trust level to edit can review pending edits. The author can also review a pending edit. Reviewers can accept or reject.

  • Not doing “…and edit” / “…and improve” – if you want to edit after an edit, then add another edit.
  • How many approvals are needed, from reviewers other than the author? Don’t say two just because SE does; what’s the right number?
  • Intentionally omitted: edit review queue. We don’t have review requirements for MVP (yet, at least). We’ll need some way to surface pending edits, but it doesn’t have to be a review queue. Maybe there’s just a list of links to posts with pending edits available?

Flags

Users can flag posts and comments.

There is a default list of flag reasons plus “other” (free text). List TBD.
There’s a a flagging mechanism. There are no types of flags.

For questions, “should be closed” is an available flag reason. Close flags are like close votes except for not being votes.

Users with the ability to handle flags see an indication of a flag alongside the content. Acting in accordance with the flag (deleting the target, voting to close, etc) validates the flag.

Moderators have access to a list of all pending flags.

Closing and reopening questions

Questions can be closed if there is some problem that prevents answering them. ( Need to find the forum post that proposes short list of close reasons. )

Closed questions can be reopened.

In both cases, a voting affordance on the question is available to users with the appropriate trust level.

TBD: Number of votes needed to take action.

TBD: messaging to author of the question.

The author receives a notification if a question is closed or reopened.

8 Likes
2

People are talking about lots of things that aren’t MVP – chat, review queues, reputation in various forms, and more. I’m concerned about the amount of focus on things that don’t need to be decided now.

Don’t mistake all that forum discussion for MVP contents.

What in particular would you remove from the functional spec for MVP? That’s the list we should be working to, not all the other stuff. I see one suggestion in your message: instead of having flag types (we plan a few default reasons and “other”), you’d like to have either just a flag or maybe just “other” (can’t tell). That difference doesn’t seem like a week’s worth of work to me, but if it is I agree we should discuss whether we need flag types right away.

What else would you cut from the scope described in the spec?

6 Likes
3

I do, however, have concerns about how many people will actually look at an MVP and be like: “Looks good. Create.” Will our MVP be enough to sway people?

4

Before offering a list I want to highlight two things.

Firstly, with this list I do not want to say any of these features are bad. I’m just saying from an MVP design standpoint they probably don’t need to be there at launch.

Secondly, don’t take estimations about how each of these features individually take too seriously. In product management speak our development velocity is completely unknown. The only thing we do know is that for each feature we do work on we don’t work on something else.1

Lastly before the examples. This is not about any of those features individually. This is a challenge to what we consider our MVP and how we want to go on with deciding what’s in it and what’s not.

I would list the following under non-MVP which are currently listed as MVP-consensus.

  • Tag descriptions (including all the trust level issues and editor necessary for that)
  • Almost everything regarding user profiles which is implicitly defined in other discussions
  • Trust level based rate limiting
  • Flagging complexity
  • Close reason complexity (Leave it at one, have meta figure out the rest)
  • “New contributor” label (By definition everyone is a new contributor on launch)
  • Threading of comments (which is easy in DB, but a hassle in UI)
  • Sockpuppet investigation by Admins (They are admins, use the DB)
  • Any site categories beyond Main & Meta
  • Most of the tbd sections of the functional spec, e.g. “for each post, access to the feedback feature (to be further specified separately)”

One last thing to consider. Any MVP is designed under the assumption that development continues through launch day. Descoping something in MVP does not kill a feature.

1 At least for all intents and purposes we cannot assume in designing an MVP that we have an architecture that allows infinite parallel development on core features while still “staffing” the parallel streams with enough developers.

7 Likes
5

You talking about “velocity” made me realize what is probably the crux of the issue.

Cause that’s an Agile keyword.
Can I assume you’re used to that way of working?
Because I do, and I 100% agree with you.

Most of these MVP posts however, are in a waterfall mindset. There’s the big MVP release date, and there’s this list of features they want in there.

1 Like
6

While I disagree with some of the things you were saying earlier in this thread and in Discord, I find myself agreeing with most of your specific suggestions here.

To clarify: I think we have different ideas of “minimum”. I don’t believe our MVP should be a Mighty Viable Product, but I do believe we’re envisioning different levels of “minimum”: specifically, I do not want or think it’s helpful to be embarrassed by the first version of our product. We’re going to need to capture users, and the only way to do that is to give them something better from the off, not to give them something that we can just about get away with and say “more is on the way”.

However, your specifics:

  • Tag wikis: yep, don’t need to be MVP.
  • User profiles:
    • Stats for next trust level: not MVP, just have a help page that lists them, folks can work them out for themselves.
    • Lists of Q&A on profile: disagree, this should be MVP. Being able to see what a user has posted is an important feature.
  • Trust level based rate limiting: if you mean the “TL1 can only post X Q/day”, disagree: that’s part of our privilege and reputation system, which is a core feature.
  • Flagging complexity: not MVP, simple textbox is fine (that’s what Writing has now)
  • Close reason complexity: not MVP
  • New contributor label: eh - not necessary for MVP, but also really easy to implement so we kind of might as well
  • Comment threading: disagree, this is a core differentiating feature
  • Sockpuppet investigation: not MVP, we’re not going to have those problems in the early days, so that can be v1.1
  • Categories beyond Main/Meta: two minds about this. On one hand yes, those are all we’ll need in the early days; on the other, again it’s a core differentiator.

I suspect some of this is the product of things that weren’t intended for MVP simply not being marked as such in the spec, and only some is down to actual feature creep.

11 Likes
7

I generally agree with Art’s refined list.

If we do categories right, then it should be trivial to add ones beyond meta. It becomes non-trivial for the UI if there are too many, but we can set a workable limit, like 3 or 4. 3 means you get one thing other than meta, 4 means you can have two. That’s enough to get started; most communities will probably have 0 or 1, but I see no reason not to allow them to create a sandbox or canonical list from day 1. Categories are a differentiator, like trust levels, scores, and comment threading.

7 Likes
8

But I think the main purpose for most communities for Categories will be items that function differently from “Main”. Though so far all I can think of for most is the question of whether they have “Answers” or just “Post + comments”.

But there are some where additional Categories may literally be “categories of Q&A”. If I remember correctly, there was one (Physics? not sure) where they ended up with 2 separate sites - one for “ordinary” questions (but hopefully answered by experts) and one for the more advanced questions. That is the type of thing where Categories, if done well, can really shine. Migration of “this is too advanced/not advanced enough” then becomes an “internal to the community” issue instead of having to say “bad” or “send it to another site, maybe they’ll take it”.

9

Do we have a solid idea of how “Categories” are going to be selected when posting a question? Will you need to go to a different subdomain site like on SE or can you select another “super-tag” on the same page you’ve already typed your question?

10

Details TBD. But my concept is that:

  • Blog/Canonical/Meta/etc. all share a subdomain with the “main” category (and user profiles and everything else) of a given community.
  • Each Category will have tags - may be shared within two or more categories, TBD. But, for example, Meta has generally been considered to have a different set of tags than Main (If you have “Superuser” community then “spam” on Meta means “blocking people abusing the Codidact system” whereas on “Main” it means “filtering email for a domain”)
  • Moving a post between Categories should be a Moderator and/or possibly a VTC-ish item (3 users vote to move from “Main” to “Canonical” or vice versa). The catch is that once there are Answers you can’t move to a Category that doesn’t have Answers (and similar for any other “only on some Categories” feature).
11

Categories are not subdomains. You’re always on unicorns.codidact.com, and you might be on the “questions” tab or the “meta” tab or the “sandbox” tab or whatever. There will be clear visual differences.

The simple approach would be that the “ask” or “post” button posts to the currently-selected tab. (The button text could also vary by category, for categories that aren’t really about questions.) A possible enhancement would be that we offer the chance to choose a category from a menu, but I’d want to test that with mockups and actual users before going too far down that path – it sounds potentially useful for power users and potentially confusing for others, so let’s be careful.

3 Likes
12

Let’s start with: moves between “like” types only (main questions → meta questions, for example, but not main questions → blog), and done by moderators only. I’d like us to get some solid experience with how categories are used before we build a lot of tooling here; initially this can be the rare, exceptional thing for which we have moderators.

3 Likes
13

Agreed. In reality, just as with Migration between Communities, moving a post between categories could always be done by: Copy, Create, Paste, Delete.

14

If I understand it correctly now, categories is basically what we call “Main” and “Meta” on SE, and maybe there will be something else on Codidact.

In that case, I think it would make sense to “Ask a question” on Main and “Post a discussion” on Meta. Maybe change the button text to “Post a bug report” if you have selected a [bug] meta tag or “Ask for support” if it’s a [support] question for meta.

15

Well, once you’re selecting tags you’re already past clicking the button, so changing its text won’t help. I think it’s sufficient for the button to have category-specified static text. When you create the category you already have to specify a couple other things, so this would be one of them. Don’t need to specify button text for MVP, though – “ask question” by default and “post” on any other category will get us going.

Meta is not baked into the code; it’s a category configuration that we will apply to every site we host on our instance. Other instances might choose differently.

3 Likes
16

Check out Thoughts for a new Photography Q&A Site - #7 by mattdm for some ideas on how categories might work on a theoretical Photography Q&A site.

1 Like
17

I’ve marked the following as not MVP in the functional spec:

  • Tag wikis (short descriptions stay, long descriptions are out)
  • Flag types (everybody gets a textbox)
  • “New contributor” label
  • One trust level that’s currently a no-op because we don’t (and won’t) have a review system. (The trust level is there but we’ll skip past it in MVP.)

For user profiles, the spec says it contains links to the user’s contributions. We’ve talked about things like progress toward trust levels, but it’s not in the spec and I agree it’s not MVP.

I didn’t change anything about comments a.k.a. feedback. I think threading is important.

Categories are a framework, not baked in, as I noted in another comment, so there’s no reason to restrict to just Q&A (main) and meta.

2 Likes