Fibery End Game (Product Company Example)

We’re working on Fibery for 5 years already and are still far from our main goal. What is our main goal? How do we envision the near future of work? Last year I wrote a long article about these topics — Augmenting Organizational Intelligence, but it’s quite abstract and hard to apply to usual use cases. Here I want to narrow the context and show you how a product company can operate having a “future” Fibery. The future is hard to show and explain, but I’ll do my best to be as concrete as possible.

Context: Product B2B SaaS startup, post-round A, 50-100 people.

🦐 Now → Many tools

Let’ me briefly focus on the “now”. How this startup most likely operates and what unsolved problems does it have?

Typical product development company core toolset:

• Notion as a company wiki/intranet and product management
• Jira/Linear for software development
• Slack as a chat
• Asana for various projects in marketing and other non-IT teams
• Intercom: chat + user guide
• HubSpot as a CRM
• Canny as a feedback portal
• Miro as a diagram/whiteboard tool

Problems

There are many problems, but I just want to highlight several of them as examples.

1. Knowledge lives in many tools (Notion, Miro, Canny, Slack, Jira)
2. Discussions out of context
3. Customers feedback handling process is poor
4. Features prioritization process is ad-hoc and mostly based on gut feelings
5. Connection between features specification and features as work items is weak

Problem 1: Knowledge lives in many tools (Notion, Miro, Canny, Slack, Jira)

It makes invention much harder since you have to extract it from many tools and put it into some digestible format for the analysis phase. Then you have to jump between these tools: brainstorm something in Miro → document results in Notion → have a sudden discussion in Slack → jump back to Notion to add some ideas and options, etc.

People tend to seriously underestimate this problem, since reflection about working processes is not something they do often. Status quo is always there and people get used to it.

Problem 2: Discussions are out of context

Most discussions happen in Slack, but knowledge is hard to extract from Slack discussions. In most cases, there are no connections to real decisions, actions, and long-term knowledge accumulators.

For example, here is a discussion that may lead to some bug. It is not obvious whether a bug is created or not, it is hard to link the discussion to a bug, etc. Or it may be an answer to a question. In this case, it will not improve some knowledge base, it will just live in Slack where nobody will try to search for it (since Slack is not a knowledge base).

Sometimes we are posting a link to Slack discussion in a Feature. This discussion has 20+ messages inside, so copy/pasting is not very convenient. Not the best way to store knowledge for sure…

Our customers are feeling the same:

🎤 I’ve really been noticing more and more the dynamic between Fibery and direct messaging software. We’re using Pumble at the moment (Slack alternative). Direct messaging software is like a vacuum that is continuously pulling all team members and communications into it. Whereas Fibery is far more passive. Many businesses and teams move with a sense of urgency. Everything moves quickly. That really lends itself to direct messaging. So things start with questions, then small to dos and requests sneak in, then update requests and then reminders and all of a sudden, we’re using chat software for tasks and work management. Fibery sits there quietly, whereas the chat software talks to you all day. It would be great to have direct chat inside Fibery so everything was always all in one place, so Fibery is where the action is, along side all of the structured work.

Problem 3: Customers feedback handling process is poor

Feedback from all sources is not accumulated in a single place, only a basic voting mechanism may present. However, feedback comes from many places: customer calls, intercom chats, emails, etc. Votes are not the best way to capture feedback, text is much better. But almost all companies rely on votes since there are no good tools to capture and aggregate narrative feedback and quantify it.

Problem 4: Features prioritization process is ad-hoc and mostly based on gut feelings

It is not clear what Feature brings more value since feedback is not captured and not linked to a potential feature. There are some models like Kano or RICE, but they work no better than gut feelings, to be honest. We need some real hard data to make decisions about features’ importance.

It is impossible to slice feedback by customer segment and understand what segments requested what features. Few companies connect CRM to product information like features. As a result, it is not possible to prioritize work by segment and execute some strategic goals better. For example, a company may decide to focus on the Digital Agencies segment and it already has 20 customers from this segment. What do they miss? What features do they need to get more value? What features they are using heavily? You have to dig this information from the ground by talking with all the customers. While talking is always good, it is hardly scalable.

Problem 5: Connection between features specification and features as work items is weak

Features-as-specs live in Notion and features-as-work-items live in Jira. This makes feature updates and discussions harder since developers work in Jira and have to navigate to Notion to add some relevant comments. Or they comment in Jira, but the context is not there, thus making even discussion harder. In real life, the discussion will happen in Slack…

Product Owners have to jump between Notion and Jira all the time and duplicate some content (at least Feature names). Most people get used to it and don’t notice how awful it is.

😑 Why do companies tend to ignore these problems?

Most companies are blind to these internal problems. Why?

1. External problems (market, sales, customer success) are more important and you can build a great business on top of relatively unoptimized internal processes.
2. Internal process changes are hard and painful. Companies tend to avoid them.
3. This is a status quo and solutions to these problems are hard or non-existent.

Here is one quote from a (churned) customer:

🎤 So the TLDR is that myself a few others on my team found fibery so incredibly powerful and flexible. Everyone said “wow, that is cool!” And I tried to get different teams to migrate to it, with pilots and use cases and examples and prototypes. But at the end of the day no one had the appetite for abandoning existing tools (salesforce, hubspot, confluence, jira, asana, aha). And since so much of fibery’s power comes from when it’s the source for info, or the hub at least, that without that info being there and without users investing in it, it became just another tool, and not THE tool.

🤷‍♀️ Are these problems important enough?

We don’t really know ¯\(ツ)/¯. We don’t have solutions for them and we don’t know how these solutions will affect companies, we can only speculate. This is the edge of productivity tools right now. Maybe it will lead to a transformative experience for many companies and help them create things that were not possible before. Maybe it will lead to marginal improvements in productivity and knowledge management.

I believe a company that will solve these problems will have a huge edge over its competitors 🚀. It will understand the market, customers, and domain better, share knowledge better, focus on important features more often, see patterns that nobody sees, save time on context switching, and execute faster.

As a Product Owner, you will have more comprehensive information and will make better decisions. Better features prioritization alone can be enormously beneficial since features nobody use is waste.

🪢 Why do these problems exist?

1. Unbundling and specialization of tools solved some specific problems but added coordination and information discoverability problems. For small companies it is bearable, for a larger company coordination problems become more important and hard to ignore.
2. All efforts to bring information from these tools together did not get traction so far. Universal search bars, some ad-hoc integrations or integration platforms, and data lakes solve only some cases.
3. Some problems are intrinsically hard (features prioritization, domain knowledge capturing).

Fibery goal is simple — we just want to solve all the problems above and help companies invent things better & build things faster. We are thinking about a paradigm shift here.

Imagine you have a typewriter and write novels. Then the text editor appeared and suddenly you can re-arrange text, quickly fix typos, produce many copies of it, etc. I feel the knowledge and work management processes in companies can be much easier and natural. As a result, a knowledge worker will be more fulfilled in her job 🥰.

🦄 Future → Bundling

Our ultimate idea is that it is possible to build a single piece of software that will replace almost all tools from the list above:

• ✔️ Notion as a company wiki/intranet and product management
• ✔️ Jira/Linear for software development
• ✔️ Slack as a chat
• ✔️ Asana for various projects in marketing and other non-IT teams
• ✔️❌ Intercom: ❌ chat + ✔️ user guide
• ✔️ HubSpot as a CRM
• ✔️ Canny as a feedback portal
• ✔️ Miro as a diagram/whiteboard tool

Now imagine you have this all-in-one tool in your hands. How does it solve the problems above? Let’s find out.

Solutions

I understand that text + sketches might be not enough to assemble a complete solution, but I hope you will find some glimpses of hope below.

1. Knowledge lives in many tools (Notion, Miro, Canny, Slack, Jira) → replace many tools with a single one (Fibery)

When you have all process and knowledge-related things in a single place, information discovery becomes so much easier. You just search for what you need in Fibery using full-text search, filter search results by information type, and other criteria.

2. Discussions are out of context → discuss always in context

You don’t have Slack or any external chat app. You have all conversations in Fibery. All discussions are tightly linked to process areas, knowledge hubs, or work items.

If you want to chat about some exact feature, you go to the feature chat channel. You had a chat with developers about it and decided that some options in the specification should be changed. You mark some messages as Decision and transclude into relevant places in a feature spec, so other people can see them, read the discussion and find out why this solution is there.

If you want to chat about some general company area like “marketing”, you do it in a general #marketing channel. For example, you discussed some problems in the #marketing channel and decide to work on them. You can convert one or many messages into a new task and have backlinks between these messages and the new task.

3. Customers Feedback handling process is poor → accumulate and connect all feedback in a single place

Feedback from all sources is accumulated in Fibery: Intercom chats, calls transcripts, emails, feedback portal. Feedback is linked to accounts in Fibery CRM and to Product Areas and Features in a backlog via bi-directional links.

When you navigate to a Feature, you see all linked feedback as text, can read it, and see related account and segments. For example, you are focusing on the Product Companies’ niche right now, so feedback from product companies is super-important. You quickly review all attached feedback, filter by Product segment, and decide that it should be a part of a feature spec to highlight the problem. You drag and drop it into Feature spec.

4. Features prioritization process is ad-hoc → collect and use hard data to score features

When you have all feedback in Fibery, you can finally use hard data to prioritize features. What feedback is more important? Most likely from paid accounts, your target segments, larger accounts, etc. You can create a custom formula to calculate Feature importance based on strategic criteria and rely less on your git feelings.

5. Connection between features spec and features as work items is weak → remove this false dichotomy and merge them

Knowledge and work items are not separated. Feature spec lives inside a Feature, and Feature is moved by states from development to release. All communication about Feature happens in Fibery and is linked to Feature, so you can trace decisions-to-discussions and back.

Why it is possible?

Indeed, every single vendor in the list above is a large product with relatively large teams behind and $100+ billion dollars capitalizations in total. How on earth you can replace them all?

At scale, all B2B products converge. It’s reports, alerts, workflow, permissions and approvals all the way down. https://t.co/eRn9klViOS

— Parker Conrad (@parkerconrad) August 24, 2020

Here are my arguments for why it’s possible:

1. It’s possible to create a product where you can replicate any domain. Essentially, it’s a database LEGO where you create tables, and relations on the fly, evolving them the way you need anytime. This is what we have already done at Fibery. Problem solved. We can replicate the static structures of the all tools above. [✔️ solved]
2. 80% of UI in these tools is the same. You have tables, boards, timelines, and other views everywhere. Every single vendor reinvents the wheel over and over again creating custom UI representations of the domain data. Sometimes I wonder how wasteful is this, but you have to own your components to improve them based on your users’ feedback and new data. It’s possible to create a set of UI components that will fit almost all use cases good enough. This is what we have at Fibery partially. Some UI components we have are crappy, but, again, this task is doable. [✔️✗ almost solved]
3. It is possible to create a workflow/rule engine that will close 80% of automation cases in all these tools. Again, many vendors solved this problem already for specific domains, but with some basic generalization, it can be solved for any custom domain. We have a partial solution and a path to the full solution at Fibery. [✔️✗ almost solved]
4. It is possible to implement a general permission schema that will work for any domain. This problem is solved in many tools, but not for any custom domain. We don’t have the ready solution, but we have a conceptual model of how it should work and going to implement it this year. [✗✔️ not solved, have a concept]
5. It’s possible to create a tool that mixes structured (database) and unstructured (text/diagrams) information in a good way. This is not a solved problem, but we have good attempts (Notion, Coda). As a side-effect of this belief, we think that it is possible to implement good enough document/text (Google Doc) and diagrams (Miro) solutions and mix them with the other areas of a product. [✗✔️ not solved, have a concept]
6. Many other things are just replicated in all these tools: SSO, users management, billing, search, etc. You can just build them once. [✔️ solved]
7. Based on our current state of development, it seems all these problems can be solved in about 10 years timeframe for a team of 20. Note that we spent 5 years on Fibery already and nailed the most problems as complete solutions or as prototypes/rough solutions. Fibery is already “good enough” to replace some tools and shine, but definitely not good enough to replace all of them yet (and that is our goal).
8. Essentially, we created a no-code tool to help companies build all-in-one solutions. That was not expected, but it just appeared a path to the solution.

Who else is attacking these problems?

In my opinion, Notion and ClickUp are moving in this direction as well. I’m totally biased here, so please take my words with a grain of salt.

I don’t think ClickUp will nail it. They are building a very successful business, but they don’t innovate and don’t use the first-principle approach to solve problems. For example, internal data structures can’t handle various domains well, relations are poor and the product feels complicated. Maybe at some point, they will re-write the core, but I doubt it.

Notion may nail it in the future. They are moving slowly and carefully, thinking deeply. They have the same problem as ClickUp though, you just can’t build complex domains in Notion due to poor relations and internal structures. But here I believe they may re-write the core at some point to fix it.

🐌 Why Fibery may fail?

1. It is hard decision for a company to replace many existing tools with the new one. It takes serious effort and a company should understand the benefits clearly. We should learn how to explain the new future and show potential benefits.
2. There are some unsolved technical and conceptual problems: Can we handle navigation complexity for so many use cases in a single tool? What about performance for 1000+ users? How to implement the remaining 20% unique things from specialized tools, keeping Fibery as a no-code tool?

😎 Why Fibery will succeed?

Here are several arguments:

1. Fibery core can handle complex custom domains. You can’t reflect your company structure in Notion or ClickUp in a good way, while in Fibery you can.
2. We already solved many hard problems and have a full (well, 80%) vision of Fibery future.
3. We are focusing on a specific niche: product companies, while Notion and ClickUp are building very horizontal solutions. Specific niche has its own use cases, and we think that Fibery will fit this niche much better than any generic tool.
4. We have the knowledge, a cool team, and plenty of time and money.

Some quotes from different customers and leads:

🎤 We use Fibery for everything - billing, CRM, project management, customer research, publishing calendar

🎤 We made a full comparaison vs Notion, Monday and ClickUp. Data model and relationships are great, and seem to be the best way for us to leverage our data.

🎤 I’m still trialling the product but I’ve got to say, after using Airtable for 6 years and prototyping a whole management system with Notion twice, Fibery is perfect for me

🌶 Fibery End Game

No matter the vendor, I’ll bet my money on this solution (well, I already did).

A single tool that unites work and knowledge management processes, thus helping product companies invent things better and build things faster.