But we may wonder, why encourage shorter content? This is simply to increase readership. Let’s face it, with the advent of mobile technologies, the attention span of human race have collectively decreased (lesser than a gold-fish now). We are more attracted towards short, simple content and we shy away from longer forms. It is very clear that this is one of the key hypothesis Evan and product managers of Medium were going with, which is evident from the title of the blog post announcing the feature:

A Less Long, More Connected Medium

Increased readership (both on mobile and website) will increase both advertisers’ attention and authors’ willingness to create more content, strengthening the network in turn.

Hypothesis 3: Inline editor will not impact the quality of content

While providing inline editor to generate more and shorter content, an obvious concern is that it may lead to articles of lesser quality. Evan and his team is confident this would not be the case, as he calls out in the same post:

We know that length is not a measure of thoughtfulness. The quality of an idea is not determined by the polish of the writing. And production value does not determine worthiness of time investment on the web any more than it does at the movie theater.

Even with this justification, I believe this is one of the riskiest hypothesis the Medium team may have made. Things that would have given them more confidence while sticking with this hypothesis, may have been:

• Shorter posts will guarantee more eye on the content and more feedback, leading to improvement in quality.
• Improvements in Stream will ensure higher quality contents are more discovered, not impacting the user’s experience of finding good contents, and accommodating the long-tail of impulse authors at the same time.
• As readers are becoming more impatient and always addicted to new contents, they may not mind slight degradation in quality.

Measuring results

The goal of building a minimum viable product is to validate the riskiest hypothesis that the product owners are making. Hence we will also explore how Medium would have measured results to validate each of the hypothesis they made for building the Inline Editor feature. Each of the following measure can be taken on a defined time-slice (daily, weekly, monthly etc.)

Measure 1: % of posts created using inline editor

Directly measures the usage of the feature. One variant of this measure would be % of posts started in inline editor (later going full screen)

Measure 2: % increase in new posts in medium

This is a indicator of how inline editor on the homepage is encouraging authors to create post.

Measure 3: % increase in first time authors

This is a good indicator of how much the feature is attracting new content providers, which is important to grow the network.

Measure 4: % decrease in average post creation time

An inline editor should help authors create posts more quickly.

Measure 5: % increase in number of new short posts

If we define short posts to be posts with less than 100 words, a percentage increase will be a measure of how well the inline editor is serving its purpose to encourage people to write shorter posts.

Measure 6: % increase in total number of reads

More content would lead to more reads by users. Further, increase in shorter posts should also increase total number of reads.

Measure 7: % increase in new readers

Are the features introduced attracting more new readers to the platform?

Measure 8: % increase in interaction on posts

Are more and shorter content leading to more engagement between authors and readers? (Engagement per post can be measured by count of highlights, shares, comments, recommends and bookmarks). This will also be a good indicator of the quality of posts (useful for hypothesis 3). This measure can be further split based on size of the post.

Defining success of the feature

Let us now postulate how medium team would have defined success. They would have defined both qualitative and quantitative measures for success. The quantitative measures may look like:

• At least 20% of the new posts will be started in homepage inline editor.
• 15–20% increase in the total number of posts.
• 10% increase in first time authors
• 30% in increase in number of short posts
• 10–15% decrease in overall average post creation time.
• 25% increase in total reads
• 15% increase in new readers
• 25% increase in interaction in posts
• 10% increase in time spent in the product per user per session

Note that some of these quantitative measures of success may be defined not only based on Inline editor feature, but based on tags and stream features they introduce along with.

Additionally Medium team will be interested in qualitative feedback as well to define success. They may setup goals such as:

• Feedback received from top 100 readers and authors via survey should be 90% positive.
• Coverage of the feature launch in the tech-blogs and corresponding feedback received from readers of those blogs should be neutral to positive.
• Survey after one-month should reflect positive mentality towards the changes from readers and authors (the gap of one month is given to let the users adopt to the new features)

Proposing additional feature in Medium

Let us imagine the set of features including Inline editing, The Stream and Tags has succeeded in achieving their goal. Medium is now able to build a stronger network, with more engagement on the contents and higher interaction between authors and readers. Then what should Medium build next on top its last success to keep the network effect live?

Here I propose I feature Medium should build next, on top of their last success:

As a Medium author, I should be able to chose to auto-share my published posts in other social networks (Twitter / Facebook)

• Using this feature, authors will be easily able to ‘select’ which networks they want to share their posts in. The user experience for the editor will look similar to what Quora has today:

• If the author selects the option for the first time, he/she is prompted for authorization. This is a one-time activity and Medium remembers the authorization with the network for future shares.

• Once user selects to share on one or more social networks and publishes the article, the user gets a toast notification confirming that the same post has been shared on the network of their choice as well. This is a transient notification and it disappears after some time.

• Medium remembers author’s choice of sharing on other networks from the last post, and for a new post, that choice is auto-selected.

Why am I proposing this feature?

At first look this seems like a small feature addition, even a ‘me too’ feature following Quora’s footstep. However, this feature has great potential to strengthen the network Medium is trying to build. Here is how:

• Improved experience for authors: One of the immediate action authors take after publishing a post is to share it in other networks where their audience and followers are present. The auto-sharing feature helps authors skip this step, in turn improving the end to end experience. Twitter and Facebook being two major social networks, these are the options provided on-screen.
• Bringing readers / followers of the author from other networks: As more and more posts get auto-shared, Medium will get the benefit of other networks. This happens today as well when a author shares a post manually, but automating it will amplify the effect.
• Delight factor: The toast notification after the post is published informing the author that the same post is shared on his/her network of choice, works as a instant reward. Additionally remembering the last choice of the author when they go on creating a new post works as a delight factor, reducing author’s work further.

What if the Inline editor feature fails?

Based on the hypothesis and measures of success I defined earlier, imagine the Inline editor feature had failed to live up to the success criteria. Now what?

What does the failure tell me?

Given the level of measures we defined, we would get a good idea regarding what was not working. For example, possible failures and observations may be:

• The inline editor is not getting used enough — this can be a experience problem. We can do some A/B testing with placement and UI of the editor to see if the usage improves.
• Inline editor does not lead to increase in number of posts — even if this is the case, does it make the post creation better experience for authors? this can be indicated by the decrease in average post creation time. If that is the case, it might not be a complete failure.
• Inline editor does not lead to any increase in shorter posts — this is a concerning observation. Probably it invalidates one of our key hypothesis.
• Shorter posts does not lead to increased readership — However, does it increase the number of authors? If it does, it might be still a success, because it strengthens one side of the multi-sided platform (which will have its own effect in growing the other sides)
• Shorter posts does not increase engagement — Does it have a negative effect on the engagement? If that is the case, it is concerning, as we may be alienating the core audience of our product who came to Medium for quality content.

What would I do next?

Based on the nature of failure I will either continue on the feature, pivot on the idea, or scrap it altogether. Here are some possible scenarios that may unwind:

• Continue with the feature — Even if the feature does not achieve what it set out to do, if it provides a better authoring experience, I would still keep it. In a long term, this will account for a better product, and provide value for the user-base.
• Pivot on the idea — If the feature is failing due to lack of usage, probably I will try to tweak the experience for the end-users to see if usage increases with that.
• Scrap the feature — If the inline editor features is actually making our core reader and authors group unhappy, we may even decide to scrap the feature. A good sign of this will be decreasing engagement on posts, specially on the posts created with inline editor; a worse discovery experience due to lower quality content being created and angry hate-mails from dedicated fans.

Overall, handling the failure should be done carefully. If we plan to pivot or scrap the feature, team members, users and other stakeholders should be informed of the rationale. Moreover, this failure should not hinder our ability to experiment in future. We should be able to fail fast (by building only an MVP), learn from it (from all the measures), act quickly (taking necessary steps to pivot or scrap) and move on to the next feature with higher conviction.