This is an amazing goal. It is also a very, very ambitious and long-term one. Low-hanging fruit is arguably a better focus if there is a compelling case that it will drive adoption which would bring in more money which gives you more time/resources to focus on this genuinely difficult and long-term goal.
This is an interesting one because I’m pretty sure you define it in semi-specific but not fully articulated ways. You say “all-in-one tool for whole product company”, but what functions/app types exactly? I don’t think you mean to replicate e.g. Figma, right? Or ConvertKit or other email/marketing solutions? Or website platforms/CMSs? There are probably dozens of tools that I am fairly sure you don’t intend to handle “good enough” to fill the need for a typical product company. You may well have articulated more specifically what those areas of functionality are that you do focus on (“work management” is the best I have seen, still quite vague, and also seems arguably narrower than some of the things you want to implement). But I think it’s worth pointing out that exactly what falls into this category, what tools are necessary/important, varies by company, and also perhaps worse, the needed level of “good” to be “enough” is different per-company! This makes it rather a “fuzzy” and thus challenging thing to do. I guess you aim for the 80% case of covering 80% of some potential users in some chosen company category(ies), but still it all feels a bit nebulous to me. Feature creep waiting to happen.
Being able to focus on 3 is actually pretty good! Impressive with the current team size, especially. And of course increasing the team will not necessarily (or perhaps likely) increase your capacity in the near-term, at least in my experience. You would hire say 2-3 new developers, increasing your dev team by, what, 20%? Maybe 4-6 months from now they are able to contribute all at the same level as developers, right? And then maybe you can handle 4-5 areas at once. Growing the team is a tough challenge in itself.
100% this. Heck, 200%! I believe this is one of the major differences between Fibery and other, more successful tools (Airtable, ClickUp, Notion…). Fibery for the most part does not have a really low bar to some immediate sense of utility, except for a minority of people, IMO. For many other tools like those I mentioned, the initial experience is easy enough, it’s quick enough to get to a place where the tool is providing real value, and that makes it “sticky” enough that people keep using it. Even if they’re initially only using it for one thing, it does that thing well enough, and then they have time and incentive to discover the other things it does well, even if they take more effort.
This is I think what Notion did really well. Doing complex stuff in Notion is actually genuinely terrible, but the easy stuff is really easy (and pretty!), and that’s what hooks people. Their model is almost entirely based around hooking people for solo use first (hence the generous free tier) and then people wanting to bring that into the workplace because they already like and are experienced with it. And hey, it’s the “easiest way to do internal wiki” and it’s cheap, so why not? And that’s how they got 10s of millions of users and some increasingly big customers.
I agree, but also just want to point out that it depends on what customers you’re targeting. Enterprise is where the real money is, without needing massive customer volume. Some businesses can successfully just go straight for Enterprise, and in those cases it may be the best business call. I’m not sure if Fibery has that luxury (and that of course has not been its approach thus far). So I would agree that this makes it sensible to delay entity-level permissions longer and focus on the less challenging market to crack (IMO). But it’s an important point that this feature does arguably have a higher potential real-dollar value due to the customers it might attract.
Dev Time vs. Impact
What I also keep coming back to is the sense that a lot of the stuff in 3 and 4 may be simpler/easier and potentially faster to develop (fewer unknowns vs. 1, less breadth than 2, less challenging problems than 5), thus possibly gaining tangible, meaningful benefits for the highly critical new user case with less dev time/effort than making similar levels of “meaningful progress” in other areas. Of course I’m not sure if my assumptions here are true, so please give me a reality check if necessary @mdubakov ! But I base this belief partly on the approach of tackling what seem like genuinely “low hanging fruit” problems, things like Space Descriptions and other non-admin Space View stuff, or some of what I already referenced above, which really do not seem so hard to do. Again I am a non-dev, and of course I have no idea of Fibery’s architecture, so I could be way off base here. But if I’m right, then this should be a major factor in the consideration, IMO: how easily/quickly/“cheaply” you can make some beneficial changes in each domain.
Finally, I think this comment sums up a lot of what I fear is the adoption challenge for many new Fibery users:
I think that applies to much more than just the specific keyboard user case here. The “lack of polish” has a significant effect on “cognitive load”, it makes Fibery “feel” less good to work with, plain and simple. Ironically it is the “feel” of both Obsidian and Notion that has convinced me to leave them both behind in favor of Fibery more recently, but I am an unusual case.
Having said all that, I’ll just reiterate: making dev priority choices is hard, there is no real “right” answer, etc. And also yes I love many of the things Fibery has chosen to implement, some of which I might have chosen against at the time, but am still glad are there now (panels nav might be one of those, really loving it now, not perfect, but definitely a big improvement over what was).
I have some more specific thoughts on the whole Notifications feature area that I’ll post separately and link here, I think.