'Speed' perception (+suggestion that might help closing the gap)

Howdy!

A new topic as I am not intending to reduce your detailed post to this a specific part. I still wanna say something to it, 'cause I think the main reason for the recently increasing topics (forum, telegram, twitter) around criticism, negativity, constructivity or whatever you wanna call it, is to a certain degree based on opinions and expectations regarding this ‘speed’.

The above quoted statement with different wording was already in an answer to complains about the ‘speed’ from other phases of NASHs development. For example May,2019:

Our development speed is very fast. In fact, it is surprisingly fast, given the outstanding quality of our code, as judged by the experienced software developers who’ve looked into our code base (this is quite a lot of people, what with all the security reviews we’ve done).

There continously seems to be a discrepancy in the perception about the developement speed. I am assunming this has several reasons:

  1. Most likely people simply don’t have the knowledge in your teams area of expertise. So they simply can’t judge about how revolutionary the tech is that you are building. (Plus the probably dont know how long coding take in general). Thus, they indeed don’t understand why it takes all that time.
  2. We don’t see what’s happening behind the curtain.
  3. You/we always have to wait for regulatory approval / liscenses, which a) takes often a lot of time and b) is most certainly not in your hands.
  4. The discrepany in time expectations for publishing features which you gave when people took part in the ICO vs. the actual point of deployment of these features. (The raodmap of the prospect (‘wertpapierprospekt’) assumed things like the exchange launch, nex listing, staking, btc, and ltc by the end of 2018)
  5. There sometimes were certain ‘unlucky’ statements by the team with an overestimation about the development / publishing speed of certain features. (talking about sth like BTC end of the year 99%).

In my opinion a good way to -to a certain degree- solve the issues around this topic, and therefore help addressing some investor concerns, would be to spend some time to explain what has changed regarding your original product and time expectations. Is it for example taking longer than initially expected because your are building a sum of products which are better than previously planned? (Like you for example changed the matching engine plans after the ICO). Are there a lot of things that were added afterwards? Did you need some time to get more experience regarding how long building a project like this takes? Did regulatory things take/took longer than anticipated? Were the unforseeable blockers? These are just examples, but i think you understand what I think of. In my opinion it is very important to elaborate on this one, as otherwise there will be always people question themselves how you can miss your own initial expectations that far and still be surprised about your development speed. Keep in mind not everyone is following always very closely and people might not be aware of developments, so they just check and see the current state(s).
Last but not least, I assume that at least a lot of people are interested in a certain speed not because NASH is their hobby, but because they are invested in NASH and want(ed)/expect(ed) a certain dividend from their investment. In this regard I would like to once more kindly ask to get an answer to this topic as dividend expectations are very well related to possible concerns about ‘speed’.

Kind regards, J.

7 Likes

In my opinion this is quite a difficult topic here. Summarized, I would say it is about investors expectations due to the project, communication from the team to the stakeholders as well as uncertainty on the side of the stakeholders and on the teams side.

For myself I do not understand why nash is still trying to communicate “deadlines” to the community. This is something which hasn’t worked out since the beginning. But this is not unique to nash. It happens in every project which I’ve followed along. I just don’t understand why communicating them.

I mean yes, with giving “deadlines” due to certain topics (exchange launch, btc trading, nash cash, …) investors can be cooled down for the periode. But calling out a “deadline” raises the expectations for the investors for this specific day. If the team do not deliver at this day, stakeholders are getting disappointed. Wrapping this over to UX wordings would mean a user had a bad sensation. Having several bad sensations will lead to a bad experience. Should mean, having several missed deadlines result in a bad investors experience.

Another bad thing in my opinion with communicating a “deadline” is stacking the uncertainty at the teams side. As investor I feel really comfortable if I know at this moment there will happen this and that and I don’t have any kind of uncertainty until this date is reached. On the other side the developing team has uncertainty in developing the product. No one can estimate how long it will take to built a state channel based exchange with mpc wallet and BTC integration. Now adding up that the investors expect a launch at a specific day, will add up pressure to the team.

As described above… I’m not a fan of deadlines

What I would prefer is either nothing (only we are working on product one, two, three) or progress updates. Just a short summary what has happend (for example in the last 6 weeks) and if the feature is ready a Twitter + forum announcement

3 Likes

Funny you’d mention that, because Nash was a top 50 exchange by June 2020. Not bad, huh? :wink:

Claiming Nash team is not business-oriented is just ridiculous FUD :roll_eyes: Imagine your company is building a car. You know what’s more important than having customers buy it? Making sure it respects safety norms. Otherwise you’re just exposing yourself to a massive headache later. Nash will deliver great marketing campaigns when the exchange is user-proof; there’s nothing more to say.


On to the serious comments of this thread:

@JustUS’s analysis feels quite accurate and on point.

About deadlines, giving yourself ambitious objectives is a must; being publicly transparent about them is a healthy way to remind yourself everyday (and be reminded…) of what you’re trying to achieve. I would agree that giving yourself some margin is also important, but there’s a subtle compromise to find between over-promising - with the consequences that we know - and under-promising - which can be as harmful for a project: for instance, would you have invested in Nash ICO if the goal was GA in Q3 2020? In this regard, Nash team masterfully managed the community’s hopes. :wink:

Generally speaking, the title of this thread is misleading in my opinion. The topic tackled is communication and I do agree it could be sharper: news are spread across different channels (Nash’s twitter, Fabio’s twitter, Fabio’s comments in TG, this forum, etc.) and sometimes can be contradictory, influenced by a heated moment or written in a misleading way for investors. My recommendation would be to establish strict processes where every communication related to the roadmap goes through Nash’s communication specialists (@chris.fenwick, @clare,…) and is then posted on specific publicly-predetermined channels.

7 Likes

I can understand the frustration from the difference in time from original roadmap to now but I mean at this point when we are near to the finish line how is making the team prostrate themselves gonna help anything. It is what it is. Better to forget all of that.

1 Like

For sure it is important to have ambitious goals set for the company. You need to have a challenge. But imo the challenge should be kept inside the company. Including investors into the deadlines can be good, if it is your primary goal to keep them. But I don’t have the feeling the primary goal from nash is to keep those communicated deadlines. My feeling is that for nash it is all about quality, security and user experience. Working with an agile approach (scope is fixed and time + ressources are variable) also determines the time as variable. I think that is the reason why communicated deadlines often do not work out. This results in a lacking investor experience, which recently was shown by the one or the other investor.

I would have invested in nash ICO, if I would have won the lottery which sadly wasn’t the case. :wink: Keeping it short, the provided vision and the community is the reason why I’m here. Not because of any published deadline.

1 Like

Cardano used to use progress bars for different targets. I liked those a lot as it gave insight in the progress being made on developtment without giving a deadline

5 Likes

Progress bars + Release updates sounds like the best way to manage expectations, Something like;

We’re working on

  1. project 1 45% complete
  2. project 2 76% complete
  3. project 3…
    The latest release includes these projects which are now complete;
  4. Bitcoin cash market
  5. MPC for wallet/account management
  6. UI improvements…
3 Likes

While I just as much as the next guy in this forum would like GA right now but I appreciate the task that the team has undertaken.

This is engineering, programming, dealing with protocols, dealing with contingency scenarios. They are trying to build a system that has to guarantee stable operation while keeping the platform super secure amidst a host of uncertainties and possible attacks.

Myself being in engineering…you try to fix one issue it causes a different issue downstream somewhere else. Then you revisit first issue tweak parameters and try to get it working so it doesn’t cause the downstream issue again. But if you get that sorted out, another issue might pop up…It can be a painful iterative process.

The team has delivered upto this point and I can’t see any sign that they have gone soft on their drive or commitment. I’m sure they are trying their best but these guys are human after all, they can’t work magic and spring out a 100% functional bug free non custodial exchange out of a hat on demand.

4 Likes

the nash ui has greatly improved from the initial release. i’m impressed with the progress and everything is looking real slick right now. the team is no doubt talented and have plenty to show in the future, that much is certain.

customer service has been nice to me too when dealing with little issues so i believe everything is on the right track.

plus fabio has been very active on the community forum, showing a very strong leader presence. it’s hard to find that kind of dedication towards a community but i’m glad to see nash has that level of commitment.

2 Likes

If you think the project is worthless please sell your nash tokens… we all are ready to buy it at a cheaper rate.

I dont disagree with your points that nash has missed deadlines and is not yet attracting business, but i can see the foundations being laid for a really good product(BTW i may be wrong ). since it is an un- attempted problem, which is difficult, I think we would need huge patience here.

Moreover regulated products take time more than the unregulated once.

So be patient… and if you feel it is not leading no where… exit … so would I if I feel it is not leading anywhere.

Thats the investment risk an investor takes when he/she invests in any project. its your call… i am not forcing you to sell.

I like that you keep on highlighting the issues and keep the team pushing… I am not criticizing you… I am also putting my view forward in this regard…

You know what, while I can only encourage being critical, I am tired of all that negativity. This forum should have a block function.

1 Like