Lack of Work Management features in Fibery (Reminders, Dependencies, Notifications, My Work, etc.)

:100: agree

1 Like

I agree with the sentiment that some more polish won’t lead to significant growth. But I also agree that enough polish and marketing will make the difference in growth.

I don’t think Notion’s success started with the blocks but before that. It was (alongside Slite) the only really simple, elegant collaborative wiki. The databases came later, yes. But it was just simple enough to allow us and others to switch from Confluence, Sharepoint and Google Docs. That’s what it replaced for us and our clients.

I spend hours per day in Notion and it was the next generation to Atlassian and co. Fibery is in a tricky spot because it is the next generation to JIRA, Trello and Asana, but also needs to compete with Notion and co. I now spend hours per day in Fibery thanks to our client. I love it, they love it too. The way I can connect and structure a product from roadmap to dev tasks to feedback etc is great (rollups on rollups kills Notion). But it’s still death by many (not a million) bee stings. It’s hard to convince new users unless they come from Sharepoint, Atlassian and co.

While I don’t need the fancy wiki of Notion, the lack of nesting pages with blocks is making things cumbersome.

I can replace JIRA, but the truly powerful templates stuff is still limited. For example:

  • Capabilities break down into Features (check)
  • Features break down into Release Items (check)
  • Release Items can be Bugfixes or a Functionality (check) and are attributed to Releases
  • Release Items can have Tasks, which are attributed to Sprints (check)
  • Sprints lead to Releases (check)
  • I cannot assign Tasks to teams (e.g. backend, frontend)
  • I cannot see all Features that have Tasks open for the current Release (I can see the tasks on Sprints)
  • I cannot see easily which Tasks slipped (in another Sprint that doesn’t belong to a Release)
  • I cannot set the load of an Assignee in a Sprint (it’s always assumed 100%) and then I cannot see the total throughput available in a Sprint

The views are good as a starting point, but certain functionality is still limited. Like advanced (SQL style join filters). I’d think the Graph API might support it. Can I use that in a view?
There are rollups that need to be carried through and formulae that only can result in text (e.g. latest sprint in a list of relations) and not in objects. etc.

Donny get me wrong, I love y’all and what you do to bits. I fully believe in your vision and the work done with your team is amazing.
But I think it’s still a matter of getting functionality, polish and then marketing refined and it’ll click.
As they say, change comes gradually, then suddenly.

I’m rooting here (and always happy to share feedback)

6 Likes

It seems like there are happy users already on board! Here’s what I would do if I was on the Fibery team:

  1. Interview the customers with large, happy teams using the tool. Part talking heads, but a lot of “here’s what we do and how we do it” inside of Fibery (probably a good amount of blurring of confidential info, but well worth it to see that business is being managed inside Fibery.

  2. Build great “first run” experiences for each of these successful uses cases so that new teams doing similar businesses can get up and running in just a handful of clicks. Example: inventory management, asset tracking, content management calendar, etc.

  3. Focus on integrations more. I am not sure there is enough of a spotlight on this (I could be wrong).

  4. Use some sort of social media content scheduling tool (built in Fibery?) to do a sort of HypeFury style posting of content. Don’t post each piece once. Post it every month - especially on platforms like Twitter, IG, etc. where your content pieces only get a short time to live.

Hope this helps.

3 Likes
  1. In fact you can create a Team database, add a relation to Tasks and assign Teams to Tasks.
  2. AFAIK you can create a formula field for a Feature that will indicate whether it has open tasks in the current release and use this formula field to filter Features in some Board/List view
  3. What do you mean by “slipped”?
  4. Allocation calculation is often not so easy, but if you can describe what you want I think we can find a way to do it in Fibery.
2 Likes

Yes, this seems likely correct to me as well. Small wonder that I agree with a successful startup founder. :smile: Then again isn’t the fact that Fibery does not do one thing exceptionally well actually both a positioning and product problem? :thinking:

Interesting. I’m not sure the rest of your post necessarily supports this though. Your approach is basically to try to do most things that “product companies” (where is this vague term actually defined? :thinking:) need to do, and do most of them “well enough” that the collective result is “exceptional” in its own way, right? That seems like an extremely difficult and vague problem to solve in a way that is compelling enough in an obvious way to companies using existing solutions such that they switch.

My perspective is that a narrower focus or “wedge” may be a better or even necessary way to approach this. “Product companies” is not really a good wedge IMO. Oh dear, I am starting to depart from agreeing with successful product founder and I feel (genuine!) trepidation that I might look a fool. But so be it. :sweat_smile:

How do you evaluate when this has happened? How do you get there without better growth? How long can a company go with MRR < Burn Rate?

Yes, exactly. It made it really easy (and aesthetic+fun) to do something that many companies need.

They do this already quite a bit. They have a whole category on their website for it. :grin:

Thing about such cases/stories is they focus on the “won” cases, not the lost cases, which are almost certainly far more important. It’s IMO less important to know why someone chose you than why someone did not.

Don’t they already have this with Templates though? Maybe needs a bit more work, but basically there. And they are even part of new workspace creation/onboarding. It ties in to a further idea/suggestion I have about onboarding though:

This should basically just be part of the onboarding flow alongside template selection (the prompt about what kind of business/user you are), e.g. “Do you have existing data to import? Try one of our awesome integrations (clickable list) or import your CSV here → [button]”.

I do agree with this and I actually think it’s already a Fibery superpower that is not talked about or demonstrated enough. Few other tools have integrations with anywhere near the comprehensiveness and power of Fibery which can essentially replicate the data model of many other apps.

Anyway, it is hard not to be an armchair product manager. It’s kind of fun. :smile: But really there are no easy answers. As soon as you start to dig in to any obvious product niche or potential wedge, you generally find lots of products dedicated to that thing, and some doing it probably quite well, while the many others in the space fail to gain much traction, and Fibery might well just end up as one of the “also-rans” there too… But maybe, just maybe there is some clever wedge not yet realized… :thinking:

1 Like

Even though there are some dissenting voices here, I continue to agree with you @Oshyan that the lack of polish, in particular around the Work Mgmt Features highlighted in this post, is a very likely reason a lot of users stop by Fibery and move on…and agreed you need to know more about them, the ones who don’t select Fibery. We’re only speculating that the lack of Polish is why a lot of people aren’t here, but I deep down believe it must be a reason because Fibery is so great at so much else. I think @Matt_Blais is on-board with some of what you and I are saying as well when recently he pointed out a lot of the keyboard annoyances, none of which I’ve seen addressed in a long time. This type of stuff, along with how comments and notifications work, can make Fibery look like it’s still in Alpha - I get that response when I demo it to people or try to suggest it. Most everybody is expecting some more sophistication on Comments and Notifications, which are two key pieces in just about any app that manages any kind of work. And I will also add that my team actually is a product team, and we have the biggest issue with Fibery in how cumbersome comments and notifications are. Like being able to just “heart” a comment to show you read it.

I will say here that re: integrations, the fact that most aren’t two-way makes them harder for me to use.

Thanks!

3 Likes

This discussions is getting into too many directions and it is hard to reply and keep context.
Ultimately, any good tool is about good use cases.
If you can have your desired use case in a tool, then you may start using it.
Then you may find some rough edges in your use case and give feedback to a vendor.
We try to map feedback to use cases. Some use cases are relevant for our vision, some are not.
I want to describe some ideas behind our thinking process and how we choose features to focus on.
Let’s take a use case that all of you know.

Example. “I want to have my company hiring process in Fibery”

What features you need to have it in Fibery:

:heavy_check_mark: A database with fields to store candidate data
:x: Form view to accept candidates
:heavy_check_mark: Board View (or Table View) to see candidates
:x: Email integration to communicate with candidates from Fibery and keep all communication in a single place
:heavy_check_mark: Notitications when something important happens with a candidate (new reply, state changed, etc).
:heavy_check_mark: Comments to discuss candidates and make decisions
:x: Maybe an integration with Calendly to setup meetings faster

These are just relatively major features that enable this use case.
Can you have it without some of them? Yes, but it will be far from ideal without some features.
For example, you can add candidates manually without form and use your usual email client to communicate, but only store candidates in database and move them from state to state in a Board view. It will work, but manual effort is huge and eventually you will abandon the solution.

Do we want to support this use case in Fibery?
Yes, we do. Any company (including product company) has a hiring process, and a candidate tracking is good case to add into an all-in-one tool.

But right now we miss

  • Form View.
  • Email integration.

Essentially, you can’t have this use case in Fibery in a good shape right now. We will release Form Views soon, so there will be slightly less pain with this use case, but a proper Email Integration is still must have to make this case sexy. So, if we want to really focus on this use case, what is the next feature to implement? Better notifications and comments? No. It will be Email integration for sure.

While notifications and comments might be non-ideal, they most likely will work fine for this use case as is.

Use case polishing
When the use case really works and we have real users for it, then we can start collecting feedback and polish the use case. For example, when Form View and Email Integration is there, we might receive feedback about communicating with candidate in other media, like in WhatsUp or LinkedIn. Or we may receive feedback about reminders to not forget to reply to candidate, etc.


When you provide feedback, we almost always want to know the context and use cases. However, this is rarely happens. Usually feedback is very generic, like “I want reminders for my tasks”.

  • Maybe this person uses Fibery as a personal task tracking tool (and we don’t care about this use case)
  • but maybe this person uses Fibery to run software development process (and we do care about this use case).

Right now we have no clear evidence that lack of work management features is what impedes Fibery adoption.

  1. From top 20 most popular requested features only two are relevant (Watch entity and Dependency tracking)
  2. We have relatively many requests about our major use cases (for example, better Timeline to handle roadmaps, Form View to collect issues/bugs/requests/…, views sharing to communicate with external people, permissions to manage access better). It means that some of Fibery major use cases are still not complete.
  3. Getting started process is rough (for the first creator it might be OK, but for team it is relatively hard).
  4. Some areas indeed are not polished and feel rough (Whiteboard, Entity View, Table View, Notifications, Comments, …)

As you see, near future prioritization is hard :slight_smile: We know the end game and it is huge, but there are many roads to it.

When you request something, I beg you to share the context and describe the use case as well. It will help us to make better decisions!

8 Likes

Some feature requests are not related to a particular use case.

For example, “Forms.”

What’s the use case?

There are too many to mention.

  • We want to survey our community.
  • We want our suppliers to submit invoices.
  • We want to accept job applications.
  • We want to enforce required fields when team members creates a new task entities.
  • On and on…

The use cases are so vast and wide that it almost seems meaningless to mention a particular use case.

When solving any issue I’m trying to solve, I want to option to use a form to give others controlled input into our internal Fibery environment, without granting them any access to data. The use cases are as wide and vast as you can imagine.

Another example, “Chat capability inside Fibery to replace Slack.”

What’s the use case?

The feature is so foundational to work that labelling it with a use case seems meaningless. What would I say? “I want to be able to direct message a team member when I have a question.”

Take another feature request, “In built reminders.”

What’s the use case?

It doesn’t relate to a particular use case.

Another feature request, “The ability to create main menu tabs across the top of an entity to better organize fields.”

What’s the use case?

It doesn’t seem to relate to a particular use case. But as a feature, I think it would be transformational to so many setups that have a large number of fields.

2 Likes

A product does not exist without use cases.
Some features, like Form View, are indeed enable/affect so many cases, and it makes them more powerful and more important to implement. I even wrote an article about it

Take another feature request, “In built reminders.”
What’s the use case?

There are many again, like

  • I send email to Teddy and want to have a reminder if he will not reply in 3 days
  • I’ve assigned a feature to Jerry and if Feature is not completed on Aug 23 I want to have a reminder about it.

“The ability to create main menu tabs across the top of an entity to better organize fields.”

Again, to show the value of this features it is better to show real cases. For example, if you have a very basic task tracker without collections you don’t need it. And you also don’t need it if you have 2-3 collections. It only start to become useful when there are many collections, like “I have a Product with Bugs, Tasks, Features, Requests, Use Cases, …, so I want to access collections faster”.

Note that tabs is a solution. In 90% of cases people requests solutions, but we don’t need solutions, we need problems. We often try to get to real problems via additional questions.

1 Like

I’m not sure your last post @mdubakov at me, but in case it was, I will tell you that my team in fact actually has the most success of all use cases probably with candidate tracking! We don’t need form view because we collect candidates from multiple other sources aside from our website, it’s not hard to manually input them into Fibery. Likewise, we communicate with them through various services directly and Email integration that would work for us would be far too complex and no tool out there has an Email integration that is satisfactory. So in fact we don’t need either to successfully use Fibery to track candidates. We in fact however have the most frustration with this use case with comments and notifications. We discuss quite a bit the candidates, interviews, onboarding, meetings around candidates, in Fibery. And it is simply frustrating on a daily basis (I say daily because probably 80% of the time for over 2 years we are doing some activity in Fibery around recruiting) to not have threaded comments, not be able to “heart” a comment that you saw it, not quote another team member’s comment when responding to it, have references and comments in different places (which I’ve discussed ways to solve a few times including here) so you can’t truly “update” an entity using one or the other, which would be great given the power of references in the first place. These are “Quality of Life” issues we’ve talked about before, and cause a lot of frustration on a daily basis.

I truly think Fibery works much better out of the box for tracking candidates than just about any other use case you are working on, in particular Product Development, which is what my team does, but we do not really use Fibery for this. A main reason is forced hierarchy when creating folder-type structures. I think I have discussed this in the forum somewhere, but it’s been a while I can’t recall where those discussions are. What I mean is we have a product structure, and one Master Feature may have a sub-feature, but another may have 3 levels of sub-feature. The only way to represent this in Fibery is create 4 types/db’s related to themselves, so in the first case the Master Feature needs 2 “artificial” levels between it and the sub-feature on level “4” (I hope that just made sense) Polymorphic would solve this, but not sure where that is on the timeline for development it’s not on the public board I noticed…Bottom line is tracking our Product Development in Fibery has not been easy, but tracking candidates was very easy to set up and we manage this process better than in any other app we’ve ever tried! And this is where the “quality of life” stuff comes up, because we encounter stuff like randomness of the keyboard that @Matt_Blais talked about daily and it’s frustrating!

I certainly hope this comment also isn’t directed at me. I have spent countless hours providing detailed use cases, I make sure to do it almost every time I post in here. A lot of my requests with use cases don’t get responses, such as this one and this one

I think @Oshyan has made a great case for the benefit of polish on some work management features, etc. that is the theme of this thread. It appears that doesn’t jibe with a lot of the live feedback the Fibery team is receiving. I continue to think that if you guys went outside your regular procedures for prioritization and focused on delivering some refinement in these areas, you’d see huge benefit.

Thanks!

1 Like

And it is simply frustrating on a daily basis (I say daily because probably 80% of the time for over 2 years we are doing some activity in Fibery around recruiting) to not have threaded comments, not be able to “heart” a comment that you saw it, not quote another team member’s comment when responding to it,

This is very useful! This is a real case about lack of good comments and I can feel the pain much better. Your feedback usually is very detailed.

I choose HR case incidentally, since I thought about it recently for our own needs.

BTW, for product management case I think all you need is nested Features, thus you can have any levels of hierarchy for any feature. Some basic feature will have none, but some complex may have 2-3 levels of sub-features.

3 Likes

Ok thank you @mdubakov that’s great to hear, glad this was useful. And yes to reiterate Fibery works beautifully for tracking candidates, it’s a core of our usage as I mentioned for over 2 yrs…

And just to be clear on this one, as I understand that capability doesn’t exist right now? Don’t mean to take us off on a tangent, but is that represented in this request:

My problem is if I have a sub-feature on level “4”, but there is no feature between to get up to level “1”

Master Feature
→ directly connects to sub-feature on level “4”

Master Feature
→ has sub-feature on level 2
→ has sub-feature on level 3
→ has sub-feature on level 4

In the first case, I have to “make up” a 2nd and 3rd level sub-feature to get to the feature on level 4.

Hope that’s clear! This is an issue for us in about 4 areas we use Fibery, also work categorization, etc. I had thought that Polymorphic would solve this for us.

Thanks again!

1 Like

This condition is perhaps necessary, but of course not sufficient…

Or you may find such rough edges in your own private/individual testing and immediately move on to the 10+ other tools on your list that can meet such use cases. Unless your tool clearly meets some particular use case the best, you will be easily dismissed in this crowded market. You know this, I’m just saying the outcome where they send you feedback instead of just moving on to other tools is the best case, and the least likely IMO.

I’m obviously biased here (at least I do have a small paying team using Fibery for some years though :smile:), but I think it’s worth pointing out that this simple binary is in my experience not actually how things always - or even often? - work. Fibery is trying to enter/compete in multiple extremely crowded markets. There are few-if-any markets/use-cases that Fibery aims toward where it meets needs obviously better than any existing tool. Generally Fibery rises above the other tools when it comes to its interconnected data model, flexibility, and thus ability to meet multiple use cases in one place.

Anyway, my point is that a straightforward approach of “let us check of all the boxes for what this use case needs” is unlikely to succeed on its own. The market is too crowded. So how else do you try to gain some traction here? Well, one potentially very viable avenue is actually to appeal to individuals first (or at least not dismiss their needs as a use case you don’t care about). Why can this work? There are several big reasons, in fact.

First, the requirements for adoption of individual tools are generally far lower, i.e. if a user tries something and likes it, they don’t have to convince their boss, or their boss’s boss, or the IT dept, etc., they just start using it. Especially if it’s free (Fibery, Notion). Second, if a user adopts a flexible tool like Fibery for one thing, they are likely to discover more things it can be used for. When a need for one of those things comes up at their job, they will probably recommend this tool they now like and are familiar with. This was a big part of Notion’s success, people using it personally, then suggesting it for use in business. Third, since they are already experienced with this tool, they can help their company with adoption, workarounds of issues, configuration, etc. They become an internal ambassador for the tool. Obviously this is not the only or necessarily best way, but it should not be dismissed so readily as I think you seem to do here.

It’s also important to point out that I totally understand the individual use case would be of no direct/immediate value to Fibery ($0/MRR), and is not an intentional part of the long-term strategy. This is what makes it a classic “wedge” though. It’s not what your product is intended for or wants to focus on, but it’s easy to support it (you have already taken a step toward that with $0 for individuals), and can drive adoption. For me personally, I am hoping that the experience I gain in implementing an in-depth Fibery workspace for my personal needs (task + projects, lots of info/databases, and “quantified self” type of stuff) will better prepare me to be a Fibery Partner one day.

I don’t want to just be argumentative, but I do want Fibery to succeed, and I do want your thinking to be clear around how to make that happen. So I have to ask: how have you accounted for selection bias with literally all of your evidence/data here? What I mean by that is you are mostly only drawing this data from people who already use, or already seriously considered Fibery as it is. And as I said already further up the thread: talking to the people already adopting or who already use your tool is not as important (IMHO) as understanding the (many, many more) people who did not choose your product.

Obviously getting meaningful feedback/data from non-adopters is harder, but that does not mean you should then believe strongly in the extremely limited data set you do have to go on. When work or dev management apps like Monday and Asana and Jira have millions of users between them, your couple-thousand-user sample size (at best; realistically I think more like couple hundred who actually give feedback via Intercom + forum + email) is simply not statistically significant to derive market needs. Do you disagree? If so, can you describe why, or how you account for these issues?

I will try to do so!

This is interesting because it aligns with my initial reaction/instinct when I read about the hiring use case Michael outlined. My basic thought was: the unsolved needs there are more or less just relatively minor conveniences of integration, and arguably do not save that much time/energy, especially vs. the power and familiarity of existing tools like email apps. I can just imagine what it might be like to try to email through Fibery vs. using Gmail: it’s probably not a good sign that I viscerally expect it to feel clunky. :sweat_smile: Especially vs. my high degree of familiarity and comfort with Gmail (for others, replace “Gmail” with Superhuman or whatever email program they love and have been using for years). In other words if you add email, just ticking the “now we can email” box is not necessarily going to be good enough to make most people care. Automated email, e.g. “You have not been selected for this job” would be nice, to be sure, but anything beyond that and I’m skeptical…

To me email integration could be nice, Calendly would be too, but the basic root of the hiring problem is a simple data management issue, which Fibery is already good at. Not only that but many companies do hiring with existing companies/systems for matching candidates with offers, which often do not allow using some custom form view. So the initial outline of needs for hiring looks like a fairly narrow view of the problem space IMO. If this is a real focus of Fibery team, I’m a bit concerned. Fortunately form view has lots of other uses (network prioritization FTW!), and email does as well to some reasonable degree…

Interestingly this is a huge example of an arguably important feature for hiring management that went entirely unspoken-to in Michael’s initial list of needed features. And I think it just further reinforces that it was a narrow view of the problem/feature set for that use case. But I agree the discussion/decision-making functions are quite important: discussing, rating, and deciding which candidates to hire is the real “meat” of the thing, and the thing not well solved by Email (or form view, etc.), or necessarily any other tool. I.e. that seems like the more significant opportunity here for Fibery to differentiate and stand out: a superior way of discussing a thing and coming to a consensus around it, using comments, reactions, voting, etc. Interestingly this is A: what Fibery has already talked about for feedback management and work planning in other contexts (i.e. it is in the Fibery long game), and B: like some of the other big features (forms, email) it too has many important use cases that it serves.

3 Likes

Don’t use several Databases/Types here. It should be just Feature database linked to itself.

2 Likes

We had many discussions around this case. Typical arguments are “see, ClickUp and Asana did great without individual focus, they are focusing on teams and it works. If we will go for it, we may start prioritize individual-focused features on top (reminders, daily calendar, new getting started), and miss collaborative team-focused features (new comments, new notifications, etc)”.

I personally know that individial-focused tool might have a better traction, but I am not sure that Fibery can move into this direction easily. But I don’t have a strong opinion here and intuitively I like the individual focus. So everything can happen :slight_smile:

Interesting, but most startup gurus advice to listen to real (preferably paid) customers :slight_smile: It means that selection bias is embedded into a startup. You have to listen to your customers that ALREADY find value in the product and improve it based on they feedback.

Ha, I don’t use Fibery for candidate tracking just for this reason. We receive 20-30 applications for every position and I don’t have time to add them manually into Fibery. It seems it depends, for some people it is OK, but for me it is a showstopper. This is why feedback around cases is so valuable, it helps me to get a better perspective about priorities and completeness.

3 Likes

For me the thing that kills Fibery dead for applicant tracking is the lack of per-entity permissions. You generally don’t want everyone able to see the interview feedback for everyone else in the company (and their own feedback if they are hired!). There are also some issues there with GDPR - there is an expectation that people’s personal data is not available more broadly than is needed. You can get some of the way there by moving the entity into a space with tighter permissions once a hiring decision has been made, but really entity-level permissions are needed.

(The ideal set-up for candidate tracking is actually quite a complex workflow; you ideally have the concept of rounds of interviews, with different interviewers in a given round not be able to see others’ feedback until they have submitted their own, to avoid bias. That would be pretty challenging to model with Fibery right now, and is probably yet another use-case for forms.)

1 Like

Agreed permissions would be helpful here, we keep our candidates in an area that the “rank and file” doesn’t have access to. Was looking over the public roadmap and not seeing permissions on there, hoping they get moved forward soon. One big issue we have with the lack of permissions is basically duplicating a lot of work-items so that we have essentially 2 sets of projects, 2 sets of tasks, 2 sets of “learnings,” 2 sets of retros, etc. between the aforementioned “rank and file,” which in my case includes offshore contractors who come and go, and the more permanent managers. Permissions would allow us to simplify and not have to do that. When we used Notion, clickup, Asana, Wrike for stretches those permissions in those apps worked beautifully to that end…

1 Like

I wasn’t suggesting a product can exist without use cases. I was pointing out that some features are so foundational that relating them to a single use case doesn’t fully express the complete meaning of the feature.

Interesting article. Rating feature importance by connectivity to other features is interesting. I’d not thought of that before.

I look at it a little differently.

For me, meaning is determined by the purpose something serves. Change the purpose and you radically change meaning.

Purpose is determined by use. What is the purpose something is being used to serve.

Consider the meaning of Glad Wrap or Cling Wrap. When you think about the item in association with someone preparing their lunch and wrapping their sandwich in it, that use determines the meaning it has.

Take that same product and use it to suffocate people. The product is identical, the meaning of it has radically changed. It has changed because the purpose it is being made to serve is completely different.

The more use cases, the more meaning there is.

So rather than taking a single use case and prioritizing for that, or prioritizing based on a feature that may or may not be densely connected to other features, wouldn’t there be some sense in prioritizing a feature based on the number of possible use cases it has, thereby maximizing meaning for the user?

Or at least incorporating that into the prioritization model. In that way, you would be working to maximize the potential utility of the product.

Independent of any competition, when I think about the very foundation of Fibery, what gives it the most value? Isn’t it the ability to create no code relational databases and then build functionality on top of them.

What makes that of such value?

I don’t see that it is its connectedness to its other features. I see that it is the breadth and depth of use cases it enables.

In fact, it is the absence of a single isolated use case that grants it its power. It’s Fibery’s unopinionated design that empowers the opinions of its users.

I wouldn’t necessarily say the more connected a Fibery feature is, the more valuable it is to the marketplace.

I would say, the more potential use cases a feature has for its users, the more valuable it is.

2 Likes

This is a fair point, but is it a fair comparison with Fibery? Both of those tools - and indeed many other competitors that “did great without individual focus” - are much more straightforward (though sometimes complex) tools. Fibery is more “idiosyncratic”, which makes it a harder sell, a more difficult thing to adopt in a larger group context. I think idiosyncratic tools do better in the individual context, at least to start.

Interesting. You have clearly thought and talked about it a lot. What are the biggest challenges for an “individual focus”? What if it’s not a “focus” so much as a “wedge”, as I mentioned? Implement a few key things that individuals might want, not reorient the whole product. Is this more manageable, something that could even be tested with a couple months of effort and a 6 month marketing push in that direction? :thinking:

Also true, except… those startup founders are also mostly suffering from survivorship bias. :wink: This is what we did and we succeeded, therefore you should also do it". Guess what: 1000s of other companies also did that and also failed. It may be a good idea, but it is not the only good idea. :grin: Lots of other companies did “preselling”, attracting an audience and even paying users before they even had a product, and ended up doing quite well this way. There are various approaches…

All the more reason to do it in a dedicated tool and not make this a core Fibery use case to aim for, right?

Isn’t this a form of “network” prioritization though?

Mostly yes.

And to whom? I would argue that a large part of that value is that it allows you to replicate other processes from other tools “well enough”. But there are processes and workflows that are so particular and so important that they arguably need more dedicated functionality to really feel/work right.

So, bringing it back around to the original topic of this thread: why is “work management” potentially so important, and perhaps more so than many other features like Form View? (in my opinion)

I believe that “work management” features (reminders/notifications, “watchers”, etc.) become needed for a great many things you otherwise use Fibery for. Let’s take a couple of use cases in this topic for example. You are doing Hiring. You have candidate application inflow, you want to prioritize/rate candidates, discuss, and decide. You now probably want work management inside of Fibery, you want to be notified when your colleague comments or rates or otherwise adjusts a candidate and you want to be able to triage, act on, and file away that notification; you want good, effective discussion features (comments); you want to be reminded to follow-up with a candidate, etc.

Feedback and Issue Management? So we have incoming feedback from various sources, we need to correlate, prioritize, and then act on it. We want reminders to follow-up with users; activity notification in case a colleague finds a spare moment and takes care of that reply already; discussion features to talk about how related one feedback is to another; etc. Basically, same as Hiring.

How about Product Teams? Well… this is obvious. :joy: Also basically same as Hiring.

Wait a minute, do all(most) all activities maybe need this stuff? Maybe! :grin:

5 Likes

I will say not “Maybe,” but “Definitely, desperately”! I appreciate you continuing the dialog, if nothing else it is now here for perhaps some other users to find and support, I am sure there are others out there who feel as strongly about this as you and I do!

1 Like