Marketing & Website Initiative Discussion

Valentin Ganev

Factomatic
This is a hard one for me. I completely agree with Matt here, but we are on of the parties with a proven track record.

The problem is that some ANOs don't have this track record. They will need to build up a record as well of course. But it completely doesn't make sense to bring leads to ANOs that are not equipped to handle them. We need to think this through really carefully. Because we all benefit from converted leads.
If we have a single entity handle all leads -- which is effectively what will happen if we use a Contact Us form that submits the data in plain text to a server controlled by a single party -- what will happen is that even companies with a proven track record will have no guarantee that they get any of the leads. The party controlling the server can choose at their sole discretion whether to disclose those leads or not.
 
Thanks for the clarification @Valentin Ganev :) Apologies for misinterpreting.

@Matt Osborne how do you feel about that from the marketing side of things? You get your contact form. We have certain approved parties for leads taking turns, Valentin gets his encryption, and all other "tickets" are handled collaboratively based upon their type?
Sounds like things are moving in the right direction, however leads should not be distributed randomly IF WE KNOW the potential end-user is looking for something specific (assume they put information in the "contact us" a text box). For example, if they want mortgages, give it to Inc. That lead should not go to someone else.

RANDOM THOUGHTS
We've had Guide elections, ANO elections, and a grant round (competitive rounds). Therefore, I'm wondering if we need elections for both:
1. People that oversee the leads
2. People that receive the leads

For the people that oversee the leads, I am wondering if we ask people from the FCT community (non-ANOs) to distribute these leads? Also, if the website ends up getting housed under a non-profit, maybe it is a requirement of the board members to distribute the leads? That kills two birds with one stone.

While we figure this out, I'd like to make sure that leads come in don't sit their stagnant, unanswered though. Can we at least agree on giving them to Factom Inc and/or Sphereon for the time being?
 
@David Chapman -- thinking about this some more now. I don't think a round-robin approach would be possible, as this would require trust in the server running the website (as the server needs to "remember" who's turn is next). What I believe could work is choosing the ANO at random every time a form is submitted. This is also a fair procedure, although in the short term we might have an ANO receiving multiple leads, while another one hasn't even received their first one yet, but in the long run things should equal out.

That said, I realize that with this place we've only solved a very small part of the problem, since we still have to figure out the process of how a lead is handled ones it's decrypted.
Valentin, I just wanted to say that I love your desire for decentralization and not wanting to trust people or systems. As a former politician, I know all too well that people and systems cannot be trusted. Your engagement keeps me on my toes and thinking. While I share your distrust I tend to focus more on efficiency. Inefficient processes drive me fucking nuts as I know how badly they can effect everything built on or around them. In addition to the trust issues I myself developed, the inefficiencies I saw in government were mind blowing.

It's critical that we be efficient but it's also critical that we be able to trust that our data is correct and has not been compromised. So while you and I probably get frustrated with each other on occasion, it's important that we realize we're both right :) It's about finding solutions that are efficient but that can also be trusted.

Yes, we can do a random approach. Or, we can have a GUI with the order of recipients and have that be Factomized. Either works for me.

Sounds like things are moving in the right direction, however leads should not be distributed randomly IF WE KNOW the potential end-user is looking for something specific (assume they put information in the "contact us" a text box). For example, if they want mortgages, give it to Inc. That lead should not go to someone else.
Matt, electing a single or couple people to distribute leads is going to be ripe for exploitation or at the very least, distrust.

If someone receives a lead that isn't within their focus, they can always negotiate with other entities they think it would work for. Let's let businesses conduct business.
 
Matt, electing a single or couple people to distribute leads is going to be ripe for exploitation or at the very least, distrust.

If someone receives a lead that isn't within their focus, they can always negotiate with other entities they think it would work for. Let's let businesses conduct business.
Leads should be distributed efficiently, not randomly. We already have a system of checks-and-balances on the protocol (e.g., both Guides and ANOs needed to ratify Governance). I am sure we can figure out a way to put a system of checks-and-balances on this as well.

The assumption that a party receiving a lead in, say, tokenization would then take "negotiate" a deal with DBGrow seems a little pie-in-the-sky to me. There's a very good chance they would keep it for themselves since there's way more money to be had that way. Additionally, if they did just hand the lead off to DBGrow and take a cut, I am not sure this would sit well with the community, as that ANO basically did nothing other than forward the lead to DBGrow, but still profited.
 

Valentin Ganev

Factomatic
David, I appreciate your honesty.

I have raised concerns about some of our processes and I am fully aware that on many occasions people could have felt hurt or attacked by my comments, as they are often more aggressive. I want it to be known that the only reason I speak this way is because I am very passionate about decentralizing trust. I think it's important that this is one of the core values of a diverse community of startups, built around a blockchain. I have no reason to distrust fellow ANOs and I'm sure (almost) everyone is doing their best to bring value to the protocol. My motivation is to minimize the probability of conflicts, arising due to centralization. I am convinced that this is very important for the ecosystem.

I am also fully aware that decentralization leads in many cases to inefficiencies and I fully sympathize with your "appreciation" for them. Finding the right balance between efficiency and decentralization is very tricky and my hope is that these discussions -- with strong opinions on either side -- prove valuable to designing robust and multi-faceted solutions.
 
Last edited:

CryptoLogic

Crypto Logic
As an infrastructure ANO we are kind of on the sideline on this one, but..... Would a medium-to-short term solution be to create an ANO-only forum where all the new leads are posted as soon as the mail is received?

DBGrow could be responsible for posting the email, but the address could be configured so it also sends a copy to the guides to provide transparency/history for the received emails.

With "one thread per email" there could be a quick discussion about which ANO follows up on this specific lead, and we could also have and maintain a list of eligible respondees. There could also be a very rudimentary system in place where the "previous" ANO who got a lead should not get the next one unless there was a consensus that they were the most suitable one.

We dont suggest this as the final solution, but maybe something that could work in the interim (it could technically be set up in a day)?
 

David Kuiper

Bedrock Solutions
It is clearly in the best interests of all FCT holders that we optimize for lead collection, thus maximizing EC usage.
We MUST maximize EC usage, even if it means hurt feelings.
I think we can all agree that the ultimate goal is to get as much end-user activity as possible, correct?
Obtaining end-users is arguably the single most important goal of the protocol right now.
Hey @Matt Osborne. I want to push back on the idea that the protocol website should optimize for lead collection. In my opinion, optimizing for developer engagement is equally if not more important. DBGrow is doing a great job on the website so far, and it’s only the initial release. But its been strongly pushed in one direction, and I’d like to give a different point of view.

I agree with you that we need to increase usage of the Factom network. My position is strictly about the priorities of the protocol website.
  1. Our max potential EC usage is directly limited by the protocol. I believe we can easily reach the current max capacity with ANO projects alone. If we’re generous and assume our current capacity is 30 TPS, that gives us a floor price of $1.06, and no room for additional end-users. If we invest in attracting core developers (medium-long term investment), our return will be protocol scaling and stability to support the global usage we all want. We cannot rely solely on Factom Inc., 2 Sphereon developers and Luap. Is there a better way to attract core protocol developers than through the protocol’s website?
  2. Let’s assume we have all the TPS, stability, and core developers we need, and our only goal is maximizing EC usage. I would argue that building a strong ecosystem of developers and companies building 2nd layer solutions on top of Factom will lead to far more usage than focusing on getting a handful of companies more clients.
This community defers to tech people for tech decisions (as we should). The reverse should be true as well when it comes to other endeavors, like marketing.
I’m not the only one with this opinion. 53% respondents to the marketing survey prefer the committee to focus on Developers and 43% prefer to focus on Enterprise customers, a fairly even split. I appreciate all the effort put into initial creation of the website, and think it’s a great starting off point. Now that we all have access to the site, I hope we can have a more inclusive discussion of its purpose.
 
I want to push back on the idea that the protocol website should optimize for lead collection. In my opinion, optimizing for developer engagement is equally if not more important.
It's a balance of both. I never meant to insinuate we ignore developers.

I’m not the only one with this opinion. 53% respondents to the marketing survey prefer the committee to focus on Developers and 43% prefer to focus on Enterprise customers, a fairly even split.
Yep, but that doesn't mean that this was the best business decision. It simply means it is what the community "thinks" is the best business decision. Are all the people that voted qualified to provide input on the optimal way to build a company (which is pretty much the equivalent of what we are trying to do)? Do they all have experience in this? I'd argue no. Therefore, I don't place much weight in a community vote on this. And before anyone says, "wisdom of crowds," I'd like to say that wisdom of crowds is great for estimating the number of jelly beans in a jar. It is not great for crowdsourcing technical decisions where experience is required.

While I'm sure that comment angered a few people, I'd like to point out that I have always deferred to the technical community when it comes to voting on technical decisions because I am not qualified to make that decision due to lack of skills/experience.

If we are to succeed, we need to defer to:
the tech experts to make the tech decisions
the marketing people to make the marketing decision
the sales people to handle the sales leads
etc.

Name one successful company in the history of the world that crowdsources all decisions, one company that would take a company-wide vote on a complex tech issue instead of letting the tech team handle it. You can't. It doesn't exist.

We need to play to our strengths if we are going to succeed.
 

Jay Cheroske

Bedrock Solutions
My (probably flawed) thinking:

* The Factom Protocol website belongs to everyone interested in building upon the Factom platform in some way.

* If an organization wants more control over website content, leads, etc, it is free to build its own website. It is also free to network with other organizations (e.g. ANOs) to build consortium websites.

* The future of Factom is one where there will be a huge developer community, fueled by a huge sales community. Most developers and sales folks won't even work for ANOs; they will work for companies doing some type of Factom development.

* Any ANO that wants to pursue sales should be in the same situation as any non-ANO that wants to pursue sales. ANOs are not a special club, except in so far as we are the ones who run the servers.

* If ANOs are to gain access to leads generated from the protocol website, then non-ANOs should also be eligible to receive those leads.

* Lot's of businesses make products, but don't sell them directly. They have websites that direct you into the sales pipeline. Factom isn't so different. A protocol website that's focused on the protocol, and that directs visitors to individual ANOs, or to a consortium of all direct sales ANOs, would be similar to many websites I've used.

* If a group of direct sales ANOs got together and built their own website, I don't think anyone would have a problem with putting prominent links to it on the protocol website. Furthermore, they would be free to implement whatever strategy they wanted to distribute leads.

* Short-term realities might require us to compromise on some of these ideals. We should make those compromises consciously, and endure them for as short a time as possible.
 
Top