last day (1 day later) » 

16:47
28
Q: Avoiding half-baked experiments: Setting clear standards for experiments and rollouts, beyond “Minimum”

M--N.B. Please note that while this post talks about MVPs (which we may or may not agree about their scope and definition), it is mostly concerned with experimental features (whether a graduated product or not). Discussing “viability” is part of the issue, but I did put out a list of questions, whic...

M--
M--
@NoDataDumpNoContribution Yes, there are. I did ask What examples of “just right” MVPs have you seen on Stack Exchange?
@EmmaBee I made that distinction. Wherever I used product or feature or experiment, instead of MVP, I had that distinction in mind. That said, even an experiment should be viable to some extent; not because it might graduate some day, but because otherwise you cannot rely on the results to make decisions (This makes it harder to revisit promising concepts later). For example, results that were shared after the comment experiment were vague, inconclusive, and if I may, not even remotely scientific.
@EmmaBee your examples for MVP and not -MVP, should all be MVP/MVF. See this, specifically: "A minimum viable product (MVP) is often mistaken as the first general release of a product, the initial offering that is good enough to address the early market. But for most products, an MVP should be a much earlier and cruder version that acts as a learning device—a means to test a crucial assumption and make the right product decision.". Even experiments should be minimum viable features/products.
I like the breakdown of minimum "testable", "usable" and "lovable" products (avoiding the word "viable" as it could mean each of those things). All an experiment has to do is validate or invalidate a hypothesis. A fake door or pretotype can do that even without core functionality.
M--
M--
@Connell I understand that MVPs are a bit of controversy, but let's focus on the questions that I've asked. For me, an MTV ;) is good enough, granted we have answers for the questions I put forward.
@M-- well I agree with others that there'll be different definitions for different things, but in the case of experiments (e.g. comments), we're talking about the MTP, then the only real requirement is that it validates a hypothesis. Plus, yes, should be included in the opt-out switch
M--
M--
@Connell well, I don't think it validated the hypothesis. For instance, I think the UI was partly(I am not sure how much) responsible for the reduction in "thank you" comments. That is a negative for an experiment. But I don't want to discuss that example, it has its own post on MSO. I rather talk about the questions in general, and if needed, we can refer to examples for context.
16:47
@M-- I partly agree, we can learn from that example how to better ensure the hypothesis is validated. I use that example because it is one I worked on myself recently. More generally though then, do you think there are any other criteria for an MTP other than validating a hypothesis and allowing users to opt out?
M--
M--
@Connell no, but validating a hypothesis is a loaded criterion. It needs sensible measures and independence. If you run an experiment that has multiple moving parts and factors, the hypothesis is not tested properly to be validated. Hence, asking for early check-ins with the community, in a chatroom for instance, to polish the idea, avoiding pitfalls, and effectively testing the hypothesis. IIRC, you said that you liked the idea/feedback of separate buttons for comments, thank you, and follow-up; +this comment.
@M-- generally I'm in favour of earlier user feedback. Perhaps counterintuitively, that also means releasing early versions to gather user data. But yes I think more qualitative feedback from the community at early stages would be great (as long as it's not just added process that delays releases and therefore delays the feedback we can get through experimentation)
M--
M--
@Connell I don't have anything against this. I think a call for feedback in a dedicated chatroom (instead of a formal announcement, or at least prior to the stage that an announcement is planned) would help you to tweak your experiments accordingly without duplicating any efforts (when you're closer to rollout) and hindering/delaying the process.
@M-- when you refer to experiments that "lack core functionality" or "shipped without essentials", I am reading that as a minimum "usable" product (which may have been the confusion earlier). What core functionality or essentials would you put on a checklist for a minimum "testable" product?
M--
M--
Discussions is a good example. It was branded as a replacement for Chat to bring humans to the forefront.
It was an experiment after all.
16:50
So I personally wasn't involved in Discussions, but from the sounds of things, perhaps that was more a case that you'd expect to be a "usable" product? Because it aimed to replace something?
M--
M--
I mean It lacked the features that apparently Chat didn't have.
Search!!! I can search chat, yes, it's not effective.
But Discussions doesn't have any search capabilities
We have asked for those features, but instead of getting any, the experiment was expanded to all tags
Whereas most of my comments are coming from the view of the recent Comments experiment, where, sure it wasn't perfect, but in my opinion it didn't need to be, we just needed the minimum amount of effort that would prove if a few ideas could work
M--
M--
@Connell I don't want to get hung up on that certain feature (or any examples for that matter)
I have (and others did too) some ideas on how to implement that experiment, but yet it was fine (for the most part besides the impact it had on Discussions)
p.s. it is a lasting impact
as I said in my comment under cocomac's answer, I am hoping to get devs like you (and honestly others who are not as active as you are in Meta) to use the resources available to them, namely, the community feedback
8 mins ago, by Connell
@M-- generally I'm in favour of earlier user feedback. Perhaps counterintuitively, that also means releasing early versions to gather user data. But yes I think more qualitative feedback from the community at early stages would be great (as long as it's not just added process that delays releases and therefore delays the feedback we can get through experimentation)
that's fair enough, I don't want to tread the same ground over and over either, but it is the only feature you mention that I can really comment on. I'm just a developer here, and I've only got involved in a few threads on meta to discuss our early releases and experimentation approach
M--
M--
This one is a great sentiment ^^
(y)
17:02
I'm happy to talk generally about that approach though. The opt-out switch was something I pushed for internally and developed myself based on feedback on meta. And I'd do more things like that if it'd improve the way we experiment
M--
M--
Great to hear... I admit I am not always available on Meta or Chat to discuss, but The Meta Room on SO and The Tavern on the Meta are both great venues to start chatting about general ideas
I'll admit that this is the first time I've used Chat...
M--
M--
more niche subjects, like a specific experiment, could benefit from a dedicated chatroom (temporary ones that will be turned into gallery mode when an announcement is made or the experiment goes live)
ohhh, I wouldn't have guessed that. I won't lie to you. It's not all hearts and butterflies, but usually Chat is really helpful, somewhat enjoyable
A lot of the things that I personally learned about the network comes from hanging out in rooms (not even necessarily talking, but just reading the messages)
Interesting! Maybe I'll at least lurk a bit more
M--
M--
And, as a JS enthusiast, I got to write bunch of userscripts with the help of folks in Chat (some of these guys are wizards like yourself)
awesome, see you around :)
17:10
haha, yeah the userscripts are interesting too - I have one myself to tell me I'm on a production environment. Don't wanna be posting test questions on there...
yup, will see you around indeed! :)
 
2 hours later…
19:27
@Connell Welcome to chat!

last day (1 day later) »