One of the interesting challenges that has been demonstrated through steemit.com relates to what happens when you develop both a protocol and a user interface. In our recent livestream, @ned explored the idea that Steemit Inc. was trying to do too much, and that lead to us being over-extended. I don't think it's accurate to call this a "regret" though. The real "problem" was that Steemit Inc. was trying to create an entirely new economy, and that's not easy.

From my perspective, the reasoning Steemit employed was: 1. We want to build a protocol that leverages token inflation to power user-generated content applications, 2. In order to do that it also needs to store content, and 3. In order to showcase its capabilities we need to build a user interface. These are all, in my opinion, perfectly reasonable conclusions and the error was not in allowing these to guide product development.

Defining the User

The problem, again with the benefit of hindsight, isn't necessarily that these goals are too ambitious for any organization (I do not believe that is the case), but that there is a strong barrier between protocol development and application development that can create some antergy (anti-synergy). The problem was highlighted for me in a recent conversation with someone from the community. We were talking about ways to simplify the SMT protocol that would facilitate that protocol's release. Part of the discussion turned to what would lead to an acceptable user experience. It was my contention that user experience would ultimately come down to user interfaces. They disagreed. The root cause of the disagreement eventually came down to which "user" we were talking about. They were talking about developers. I was talking about ordinary people.

It's true that developers are the "users" of a protocol, and as such, the protocol should be developed with them in mind as the "user." But the tough problem with Steem is that it is a social protocol. Its design requires network effects which means that more of its users won't be developers. Imagine, for example, that the only people who "used" Steem, were developers? I think that would destroy most of its value. This isn't really a problem that many other development teams have. Instagram's customers are advertisers and their users are people who like taking photos and posting them to internet. Their developers build products geared toward these two demographics. They are able to focus.

Remember Twitter's APIs

The example I'll close on is one that @ned made in our recent livestream about Twitter. Twitter used to have open APIs which were heavily used by developers and no doubt contributed to Twitter's ability to grow rapidly. Yet, they decided to close these off, much to the dismay of the developers who became dependent on them. We could come up with all kinds of explanations for why Twitter decided to close those APIs, but I think that fundamentally what it comes down to is that when you offer APIs, you become a "protocol" developer and your user base can become bifurcated into two demographics that are insufficiently similar if you are also building a social application that relies on network effects.

Engineers enjoy thinking in increasingly abstract terms. They seem more comfortable conceptualizing things that they can not visualize. That's really tough for most people, which might be why great engineers are so rare and so difficult to "create." Most people are extremely visual, which is why user interfaces become so important. This contrast, I propose, makes developing products for both of these groups extremely difficult.

Antergy

When you're building a product for engineers, your decision-making process should be very different than when you are building a product for non-engineers. One of our guiding principles at Steemit is that the Steem blockchain protocol should be application-specific. This enables Steem developers to optimize the protocol for a specific use case, making it more performant than general purpose protocols. But when you are designing products for two different types of people, your team cannot be application-specific. Everyone isn't working together to solve the same problems ... by design. Instead, some people are solving problems for ordinary people who just want their lives to be a little easier, while others are trying to solve problems for engineers who are trying to build some tool for their users. There isn't a lot of overlap between these two things, which leads to the aforementioned antergy.

Recently Steemit Inc. had to make some painful decisions. The end result was essentially the realization that we need to focus all of our energy on Steem. It may seem obvious to some, but the challenge is that as the people who architected the protocol, we feel we have a lot of insights into the amazing types of applications that people can build with it. I think that's demonstrated by the fact that when we do build interfaces for it, they seem to strongly influence the interfaces that other people develop afterward. On the one hand, I think it creates a sense of obligation within the team to build those interfaces and guide that development. That is certainly important work. I think that's valid. On the other hand, it might lead to this antergy problem which can strain resources and fragilize the organization.

Know Thy User

These are tough questions and I don't think it's possible for anyone to know the "right" answers. You just have to do your best and adapt as you interact with reality. We've just been given a serious "reality-check." As painful as it is, we have the opportunity to integrate the information gleaned from this experience to make Steem better than ever.

Know Thyself

At the end of the day we are protocol developers. Steem remains (IMO) the best blockchain protocol for powering applications and that is no small feat. I think a big reason for that success is that the team is incredibly good at understanding their customer, developers; what they need and what they don't need. Any help you can give with respect to how we can serve that customer best is much needed during these difficult times. But I urge everyone to bear in mind that there is a big difference between "ordinary users" and "developers." And if you don't agree ... let me guess ... you're a developer ;).