Hi folks,
Here is the Fibery 2.0 foundation. I know it’s quite abstract and lacks many details, but I hope it will provide you with the main direction we are going to move Fibery in the next 10 years. Your feedback is much appreciated!
Since this is an abstract vision, I wanted to just bring awareness of an area that I’ve had experience in. I don’t think it needs to be addressed in the article but wanted to share.
There are systems/business modeling languages (SysML, BPMN) that implement structured visual modeling concepts that do define explicit and reusable relationships. So, with these systems, you are building the model visually, which is then turned into a database under the hood that can be queried, generate reports, etc. With Fibery and other general-purpose tools you are modeling the relationships and entering the data more directly, then generating visualizations from that database. So it is generally coming at this from the opposite direction.
So, my comments are just:
- There are attempts to generally tackle this unified domain-modeling and integration (SysML specifically), but Fibery and related tools make this more accessible. Just being aware of that kind of tool might help with ideation or whatever. In the DoD world, wholistic domain-wide Model-Based Systems Engineering using SysML is being pushed heavily to solve the same problems you are trying to solve for a different audience.
- This is just an opinion, but I think this statement isn’t really consistent with my experience: “There are some exceptions, like Notion and Coda, they work with both to some degree, but I’d say they are closer to the unstructured world so far.” I think people might commonly use them from an unstructured standpoint, but the differences compared to fibery seem more how the UX promotes the use of the product and visualizes the data, rather than having significant functional modeling differences. I see them as having more similarities in structural modeling capabilities than differences when looking at them from an outsider perspective. This is as someone that has read the blog posts outlining the differences, which is a great, detailed walk-through.
- I’d be hesitant to say “It’s possible to unify visual data representation with just 6 Views: Hierarchical List, Board, Timeline, Calendar, Table, and Chart/Report.” For example, even in this article, you use a graph diagram that visualizes the relationships between entities. This is not an unstructured diagram, and is similar to a UML object diagram. This diagram is close to what your whiteboard supports, but iirc it only can show certain relationship types. So, I think that at least one missing key visualization type would be a generalized graph diagram. You are very close to having that already though with the whiteboard entity tree component, but that is a tree not a graph.
Questions:
- I am really liking the direction in the Headless CMS world. In the past, they were built to publish Blog Posts for the most part, but now there are many that support general modeling of any concept. (Sanity.io, Contentful, Strapi, Kentico, etc.) They often have many similar functions to build general domain models, visualize the data within workflows, then expose the data via an API. This isn’t a far cry from what Fibery can be leveraged to do, so I’m curious if you have thought at all about how Fibery fits in compared to some of these general content management solutions.
6 Likes
Thank you for your insightful comment! I quite agree with 2, Notion and Code work with unstructured data much better and indeed people may think about tables and other views inside these tools in terms of semi-structured data, but I think they are moving into a structured information direction as well. Not sure they have a good foundation for that, but still there are relations and there are entities with metadata.
I had a graph diagram in the list, to be honest, but removed it for no reason 
I do agree that it should be included in the visualization list as well as Dashboards maybe.
Two years ago when we discussed the first Fibery release Data + API was considered seriously, but we decided to move into no-code / work management space. We still have plans to add publishing capabilities in Fibery and we want to run our internal blog on it, so we are thinking about Gatsby integration at some point. Right now Fibery lacks an easy-to-use API, so GraphQL is in mid-term plans as well. Overall this should not take much effort from our side to pivot into this niche, but we want to stay focused right now.
5 Likes
The biggest difference between Fibery and Coda for me, which is the only viable alternative due to Notion’s lack of integrations, is Fibery’s App concept. I think that most, if not all of what could be modeled in Fibery could be modeled in Coda when using tables. You just end up having to make too many decisions about pages vs tables, organization by process vs department, etc.
With Fibery, you pull in an app, which contains the model for a process, then hook that to your other apps. This slightly opinionated modularity is something that I find valuable. The key value is to integrate these disparate processes across the organization, which just happens to be done by integrating these disparate tools. I think you kind of cover it in the article, but wanted to call that out.
3 Likes
Great article @mdubakov.
I am a huge fan of Fibery, and although I know that the work I do isn’t necessarily within the niche that you have identified for Fibery, it is the tool that has come closest to providing what I need (and that’s true even before all the improvements that are apparently on the roadmap).
As you may know, I am somewhat obsessed with the concept of a ‘knowledge network’ (see my post here) so there were many things in what you wrote that resonated a great deal.
What I have come to appreciate is that it is the integration of structured and unstructured data that is a key element of what will make a tool successful/valuable. I do though think the ratio of structured:unstructured will probably vary across domains. In my domain, structured information is more important/critical, and that has meant that, in the past, I have experimented with ‘structured’ tools (like Airtable, Coda, and other less known tools) in the hope that I might find ‘the one’ that fits my need.
I appreciate now that I needed to acknowledge the importance of connecting with unstructured information (even if it might not be that it forms a large fraction of what is required in the ‘knowledge network’ for my domain).
Furthermore, I have previously attempted to leverage UML or SysML in the work I do, but I have found that the barrier to entry is too high to reasonably expect model-based engineering to take widespread hold in an organisation. As @rothnic has pointed out, these tools approach the problem from the opposite direction to Fibery, but I think they are too formal and prescriptive to realistically achieve broad adoption. It would certainly be wonderful if FIbery was able to provide bidirectional data entry/editing - that is to say, changes to the whiteboard reflected in changes to the underlying data and vice versa.
@mdubakov I know that you have recently explicitly stated that you are focussing on the product management niche (and excluding others), but I do wonder whether you could consider broadening a little to encompass product development? I’m aware of dozens of tools that you would be able to strongly compete with if you were able to provide relevant app templates: requirements management, test/issue management, PDM, supplier management etc. (Jama, Spirateam, Helix, OpenBOM and even JIRA 
)
I know that you have previously written about the lack of coherence between strategy and implementation, and I wonder if the niche you are targeting is more focussed on the former rather than the latter. Might your efforts in winning over users of Aha! or ProductBoard end up diluting the strength of your overall vision?
Having said all that, I do appreciate from your recent blog post that you are discovering that customers need a really simple intro to fibery in order for it to be ‘sticky’ and since establishing beachhead is vital, a laser focus on the niche is crucial.
So you should probably just ignore me!
3 Likes
Great article!
HI, Well written! I’m also a big fan of any modelled approach, and we are just starting to use fibery.io and at the same time the project we plan getting bigger and bigger which raises the idea to move towards SysML as well. Year ago this attempt has failed already, mostly at the era of Model Driven development where the code get generated from the model. Today I would say that we are not going the way to model the implementation code. How every I have the feeling that the lack of modelling for a larger distributed system will lead to problems later.
I’m always wondering why the Software industry was never coming up with a “Standard” vision for modeling there systems. The non Software industry accepts all the super complex CAD and Drawing tools as a requirement to make large scale architectural, mechanical, 3D etc. plans without nearly noting could be build from what use on a daily basis. But why the Software industry always think that they don’t need it and work (rather successful very often) with just a small card on the wall and in cross-functional Team. Currently, I see a team suffering from not having a plan for a project. So we might start another attempt to have least a baseline SysML (or similar notation) plan before or while building
1 Like
From my experience software industry just different, it’s not a construction/modeling, but closer to a scientific research for complex projects. It’s hard to forecast and hard to plan, this is one of the reason why most companies rely on fast iterations and not on long term plans. There are niches with stable non-complex projects where long terms plan can survive, but in many cases they are not. So I don’t believe in heavy up-front modeling for processes, but do believe in fluid growth
2 Likes
That’s the problem of a startup and lack of people 
We just can’t try dozens of niches fast enough to survive. Every niche is at least 2-3 months experiment and it can just tear the product apart with all different features and directions.
I don’t afraid about out long term vision, but we have to reach $100K MRR in 12-18 months to feel relatively safe as a business.
1 Like
Yeah, 100% agree there, even as someone that spent 2 years of my life living in it during my masters program, more working in it, and wrote a paper on bitcoin about it. I don’t use it much anymore because I’m no longer working on large systems of systems and don’t think Fibery is targeted to the same audience. I feel like I kind of opened up a can of worms with SysML, so wanted to be clear I don’t advocate for an integration of some kind, but a conceptual article like this can be informed by how it solves the same type of problems.
There is this problem-solving methodology I try to be mindful of called TRIZ that basically says you likely aren’t the first to try to solve this problem and taking a broader look can help you formulate unique solutions. To see that you have to abstract your problem away from your domain, research the generalized problem, how it has been solved, then you can better identify solutions for your problem. If you take SysML’s Internal Block Diagram, its purpose is to specify/visualize how different entities within a domain connect together.
So, to know if the views supported do meet the basic needs of product development, which is Fibery’s target niche, we need to boil down the core use cases of product development to know if they meet the needs. For example, the article is about connecting the disparate models across an organization together, but think that the views specified can’t fully represent the relationships modeled for a specific instance/object without some kind of graph diagram. That is one example, but is how I’d approach knowing whether the views specified cover all the needs or they just cover the competitor’s existing capabilities.
I’m particularly focused on visualization because as outlined in the article, I think it is critical to gaining new knowledge as well. I just hope it isn’t seen as basically “done” and is continually invested in.
I particularly agree here. @mdubakov, the requirements management niche is really like a subset of Product Development, which is in a way a subset of Systems Engineering. I get that you don’t want to invest in more niches that are way out there, like the game development example, but there are many variations of product development that are very relevant, and wouldn’t require any actual features added to be viable. You’d just need a modified set of types that utilize slightly different terminology and slightly different types. This would allow you to target different keywords that just use a different set of terminology to solve the same problems with minimal investment.
1 Like
I don’t believe in big processes either, and also I don’t believe in a model driven software implementation. In terms of code generation and automatic manufacturing. At this stage the code is already the model imho.
How ever if you try to build a it system or a Plattform which interconnects 100s of sub systems of different vendors in different organizations with different teams of people, like you see in every building construction. Some planning like the orchestration architects do, is required. And they do modeling of the system with all kinds of architectural plans. I can’t really see how this can work without such plans.
Imho somewhere between modeling and drawing the whole system . Building , factory and writing the code of the software components the modeling will stop , if the interface and APIs are clearly described. For a product you solely develop your self without a contract to an external API or interface you must support and maintain the whole story might be easier as well.
Just my 2ct and experience
True , any team need app that integrate helpwiki for user feed back, user story , then ther is need for forum regard to issues , not top to bottom , need to be urgent related to real customer based , this mean need inbox ,. then ideation means for me note similar one gere with vote , the uservoice app the most expensive app , is an good example . ideation need realy idea exchange of the user forum, similar we have here …Idea exchange is a customer feedback some realy contributer role .Thus feed manager alone can delay the speed and productivity . Thus the doc based notion , coda is due to this data based wiki informations , each page well processed data into dash board in each app fiberay can add high value to all , can pay back to fiber with time too . in this context Idea exchange user feed back help regar to the new feature Road Map and Change log
chang log are issues , road map are solutions to the issues for our project .Not only our road map need to include also need to include the mile stones as well as tasks , sub tas too , how to link all these 04 items via road back is our real chalenge .
How to solve this via Road map, change loge, a milestone the project problem bundled fiber new use cases based on wiki for issues , wiki for conributor who facilitate new ideation , after idea exchange , more focus on user friendly app not for each app , but for integrated app all based doc version of real useful user friendly reports using graphical power to show case knowlege managements .We , small group trying this without sucess to achieve conectedhub based on help user voice, simple wiki made for all users of the fibery too , experiments , as learning fibery app before earning well , thanks to fibery vision of more inclusive digital app , one year is good time , we wish empower new users , ver fast , instead pay min 20 us dollar to learn from, learning lms app such as moodle , edx , canvas clases about app creation , paying one year minium 200 us dolar , spend an year , after no tools , real knbowlegde ,An integrated app learning via zoho , google , Altesean , hubspot is more expensive , more time consuming , lees flexible to reality of the startp project . Wish 2021 fibery apps move from content marketing to knowlege management of professional learning in a systematic way