Why Social App Developers Should Avoid Protocol Development, and Vice Versa

in #steemit5 years ago

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 ;).

Sort:  

My two cents:

  1. lower the operating costs significantly.
  2. Get different streams of income for steemit inc to cover the costs of servers and payslips; just selling steem @ whatever price is a totally unsustainable business plan.
  3. Realise that it is in fact unsustainable and act upon that knowledge.
  4. Reveal an updated course and vision for steem an steemit inc.
  5. Get the laid off team back on board.
  6. Focus more on steem and bring in investors once SMTs are ready.
  7. Create lots of collaborations with other companies (not necessarily crypto companies) Quora would be a perfect fit for example:
    Quora is a magnificently brilliant and simple site, where people post questions, and provide answers to others’ questions - for free. Why not tokenize this? This site has 190 million users...

Hope you read this. Thanks

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.

Are you guys willing to share some of these ideas with the community and see what the community will do with it?

Please share the knowledge and use the Steem community it's such an opportunity.

Yes, let's get this started. A large, motivated, invested and talented community can do a LOT!

I think the toughest step is to first realize there is a problem which you have done. While maybe being slightly late to the realization, I believe that the value created by the community and its passion for the protocol will allow there to be assessments as to how the roadmap will need to change. I encourage you to really integrate with the thinking of the community who will be the fuel behind executing any type of plan in the future. I look forward to seeing how the roadmap develops as there is still a large opportunity to leverage the ecosystem that has been built thus far.

Posted using Partiko iOS

I agree completely regarding integrating with the community. Thanks for the thoughtful response.

Great article @andrarchy, running a business can be hard but its crucial and critical to identify your customer. Good to see that has happened.

I am not a dev and always felt not being a dev has put me at a disadvantage on steem, obviously devs argued that was not true.

My fear is, as a creator and an experienced steem user, many of the current apps are not sustainable without steemit incs delegation. Some have no plans to really work on on boarding and most also have not much in the way of business skills and the other skills needed to make their app a business. They are devs focusing on a product, just like steemit inc.. I don't know steemit inc delegation policy, but I think its in need of review. at the end of the day, this SP was meant to be non voting SP. If the developers are not going to actually start growing a business then its a waste of the rewards pool.

So where does that leave the creator? Well I still see it as an opportunity. As a blogger prior to steem I know the value of owning content and not letting a third party have control. For Example Dlive had control over storage of replays and as I did not move with them, well I could have easily lost my content, many people did.

@steempress-io on the other had has no control over my content, if they go, my blog stays. This is very important, relying on third parties to hold your content (and earnings) is control I want to give to no one. I’m not leaving my self at the hands of someone else’s decisions.

As a content creator, I am still excited. As a business woman I am still concerned however as a steem user I am still shilling :-)

Thanks for the article.

Here are two, count'em two "freebie's"

  1. To-much-kool'aid ... steem is sick but not dead yet. When you move off AWS servers your risk for substantial hacks goes WAY up. Big institutions who spend hundreds of millions of dollars per year are getting hacked. DO you really think a small company that can't afford 2 million a year operating costs can protect there data from hackers? I STRONGLY recommend staying on AWS for safety.

  2. Steems runway is getting shorter by the day. Generate excitement again ..... that is steems only way out. If you want some ideas let me know.

BTW how do you like Jet Blue I have never flown with them?

Hey @dreamryder007, AFAIK no one within the organization even considered moving off of AWS.

If you want to help generate excitement about Steem, I encourage you to get started right now! We have our ideas about how we can get the word out better about Steem and we'd love to see grassroots efforts that could provide us with valuable information. We don't need "idea people" right now, we need "do-ers." Thanks for commenting!

JetBlue is fine, I think they tend to have more modern planes, but I'm not a travel expert.

wow this turned into a wall of text fast, sorry m8

Steem Inc. is doing a very poor job of leveraging its strengths. I will be blunt. I have some specific, executable ideas that I have not heard tossed around. I would have happily given these ideas already if Steem Cleaners didn't wreck my free vote giveaway earlier this year for copy pasting the title (I gave free votes for comments).

But first, is Steem Inc. willing to leverage its balance sheet for smaller projects? I have a project in mind aimed at helping the price of steem tokens long term. I have 100k ready to go but the price action in the market makes this to risky atm. For instance it went from .39 to .30 in just a few days and personally I don't think the bottom is in yet. I would be willing to invest my 100k if Steem Inc. made a matching offer of 100k worth of tokens.

This is one example of how business'es get leverage on funds. In this case Steem Inc. gets a project with 200k starting capital for 100k during a time of extreme crisis. I think more of these types of deals would help strengthen Steems position over all.

Also I would recommend putting together a fund raising team. It seems pretty clear to me that Steem Inc. needs to raise funds. Especially since they missed the window to self fund by selling tokens during the MONTHS that Steem was $5 - $8. They could have very easily raised 100 - 200 million during this time but FAILED MISERABLY by missing that opportunity.

Steem would also be well served to get someone with some business sense on the payroll fast before the wheels come off.

As an ordinary user for a year on Steem, it seems like the company is focusing more to take developer as 'users'. That explains too why the Steemit interface has been subpar for so long.

Posted using Partiko Android

Were arr you?

Good hearing from you. We always like it when you write.
Anyway, yep let us create awesome apps and force us to not be dependent that will make us stronger projects and companies. And if you still do want to assist small projects give them limits that push them to have a bigger game plan that means they can't be dependent forever.

In the end you guys are the only ones that are doing blockchain development there's plenty others doing apps and even some that are more than willing to step up to help with API.

Great ideas.

Hi Andrew,

Thanks for this... it's definitely interesting to hear things from your perspective.

I've often wondered this, and I hope it's not rude to ask, but what revenue streams would Steemit Inc have as protocol developers? Would it solely be the conversion of Steem to fiat to pay the bills, and would that Steem be from the current stash or would there be a way to generate more for the company?

We're evaluating different potential revenue models, but the biggest return we can get right now is from lowering our costs. We have a number of ideas about revenue and those will be much more effective once we lower the cost of our infrastructure. Not rude at all, thanks for question!

Thanks Andrew... really appreciate the response.
Totally agree with the priority in reducing costs... and super agree with the different user types... I'm going through a similar process of trying to work out how to get non-techie content rich peeps onto a front end I'd like to develop, and it's hard.. there's a huge learning curve for people who are used to instant gratification.

Hey Andrew,
I think that focusing on the protocol to facilitate devs is a good choice. What I am hoping is that it will encourage much more outward facing development than inward that aims to only draw from the inflation pool.

SMTs I think were a decent way to encourage this as it separated applications and gave them incentive to innovate for an external audience by leveraging the infrastructure to be successful in their own right. This in turn would pull people into Steem based on interest.

A few weeks back I revived an idea of locking stake which could be a way to tie investors in to Steem to be leveraged by apps for development purposes which could possibly tie into the separation of user group with investors and developers working on the Steem layer but creating for the practical user layer on SMTs.

The separation of needs is important in the development process and it is something that is getting blurred in the protocols as there are users who cross the boundaries of several groups. Investors, developers, contributors and consumers each need to be catered for but there is no line of best fit that satisfies all so creating some harder division to define spaces will also encourage users to better find their place and behave according to which space they are occupying at the time with greater understanding.

Thanks for the update, you write well and I would like to read more of this kind of thing in the future.

Coin Marketplace

STEEM 0.35
TRX 0.12
JST 0.040
BTC 71539.00
ETH 3603.23
USDT 1.00
SBD 4.75