Our team currently has size sixteen. Fourteen developers. And science and marketing. Yes, we can do several projects as time permits. How do you choose what to make? Technical thoughts on this theme. Paraphrase of a chat.

(I've been busy lately. Some very large, technical essays coming up. If you've been following my references list, then you have some idea of what will be discussed. Corresponding to more formal papers that will be published. Will be serialized as several sections per post. Also science fiction coming up as well. More on that later.)

 

      Word count: 1.650 ~ 7 PAGES   |   Revised: 2018.7.20

 

— 〈  1  〉—

QUESTION

 

``Things are going well. Our team is growing. We are X many.''

``Great.''

``So.''

``?''

``We have several things we are making. However.''

``?''

``Several things can be made concurrently. They can be made in pieces in no particular order. — Such that if there's interest parallel development can proceed. — But there's always slack. — And we may pivot, depending.''

``?''

``If somebody suggest something interesting. We're making stepping stones to other project. Yes, we can easily pivot. So can you suggest decentralized applications you think should be developed for the such and such community? You know it much better than we. You see we're not yet very active in it. Don't know that audience. What are the interesting problems in your opinion ... and that in order of priority?''

``Why?''

`Depending on the problem, how interesting it is, and what's the audience we'll pivot. Or start concurrent development. Why not?''

``...''

``Observe that we have the labor.''

``Yeah.''

``What?''

``Consider.''

``...''

``Which apps to build for community N: — that's kind of like asking "What apps should I build for community M?" They're big communities. You know that.''

``They are that.''

``Well, so it mostly depends on your target market, and on your goals, and on your budget, your marketing.

You asked a very open ended question. It does no special answer.''

 

— 〈  2  〉—

ANSWER

 

``All that is true. But the issue is that I'm not personally very active in that community — yet. Rather you are.''

``Hmmm ... And?''

``Thats' the point: — I don't know the demographics of that community. I have no real clue what they are. I don't know which audiences are the majority. — And which are not.''

``So find out. — Why ask me about it?''

``There's a good reason.''

``Which is ... what?''

``That you're sufficiently active in that community, unlike me. You know everybody there. — Unlike me. I'm busy.''

``I am; but so what? What you should build depends, like I said, on the —''

``No argument there, I agree, but I mean something else. —That usually there are 1 or 2 or 3 groups of around 5% organized among a 85% unorganized mass.''

``Why is that important?''

``Observe that they set the trend for what is considered interesting. — According to their tastes. Can you say who those are in your community?''

``Maybe.''

``This was why I asked you in particular.''

``It's a big community however. —''

``And all the same, meanwhile, there's a group that dominates. Usually is such a group. Fortunately or unfortunately.''

``...''

``Usually one must build to their tastes first, as the niche, make a buffer. — Then move on to other unoccupied niches.''

``Sure.''

``Or create new demands as desired and feasible by marketing. (More risky, but next step.)''

``...''

``The majority always runs things, yes. — But that's the point: — the only real majority is always an organized minority. For example, many apps are useful on the internet. — But if one built X twenty years ago, it would not have been as successful.''

``Sure: there's wasn't a target audience with the prerequisites. To use X and have be worth while you need first to be a user of O. And there weren't very many users of O. So too not many users of X.''

``Not only that. There's a minority that's organized, and whose problems happen to be aligned with the problem you are solving, and they all use your product. First, there's a network effect. Other products that solve the problem appear later. But if community of users affects the utility of the solution, you win. In that case you win. The combination gives you market position in that niche. You win.''

``Mhmmm.''

``Second, the organized minority pushes your product. While unorganized individuals pushes other products. Many more users push your product, at any moment, compared to users pushing other products.''

``...''

``Even if over time, more users are pushing other products. You gain further market position when search is expensive, for this reason. Other search and find you, and meanwhile, imitation works in your favor. And you win the marketing battle anyway. Many more users push your product, at any moment, compared to users pushing other products, even if over time, more users are pushing other products. You will have a concentration of force on your side. Then you gain momentum.

Any individual searching for a solution to this problem is offered your solution ten thousand times as often as he is offered another solution. Even if there are more people pitching other solutions. Doesn't matter. They're a mass, not a majority.'

One more thing. The final criterion is therefore what infrastructure dictates is the Least Cost to develop at the present point in time.

Imagine a convect curve, left to right, starting low, going up.

One can pay exponentially more to get something sooner than it would arrive from ordinary incremental investment and work.

Then use that as a tool to build what would be demanded in the future at the time when incremental growth had established that sort of technology as the most widespread. Each technology has its own problems and complementary goods. — Creates its own type of demand.

In that case one would be a first mover and if in the niche of those organized and throwing their own preferences on the market, have a buffered advantage. But this is usually the hedge product. Team B or Team C product.

Your Team A product would have to be an income generating unit that gains market position in a stable but empty niche at the present moment. Which then gives a margin that can absorb risk of paying exponentially more for the side projects, since you paid exponentially less but got same returns as if leading for at least one product already.''

``So what's Team A doing?''

``Team A should build for a niche that is empty, for an organized minority that will pump it, meanwhile a path to other empty niches and something can be costlessly pivoted itself, low risk, low cost.''

``Yeah.''

``The most important fact about space on the table is (a) that it's empty rather than full, (b) is the space where somebody will sit very soon, rather than not so soon or not at all, the space that will soon have some plate. — Whose contents by the way will determine which other complementary network of plates will follow up and fill other nearby spaces at the table.

But some dishes are much easier to make than others, given the cooking that has already been done at that moment.

What may a current organized group of users in the N community likely want to order immediately next, having what they already have, having already ordered what they ordered? And which is easy to make given the current state of the N community? (Let's put it that way.) Can you say? Asking you because: (i) you know the organized groups, and (ii) the detailed state of all other development in the N community. We don't. — And that is the point. We don't know. But we can quickly learn the answer by asking those who do know. Then we too shall know. How convenient.''

This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License  . . .   . . .   . . .    Text and images: ©tibra. @communicate on minds.com