We cloned the ProductOps tool, Dragonboat, in a few days

What is Dotwork? Dotwork is a platform that provides the building blocks for custom, integrated solutions to support strategy development, planning, execution, and adaptation.

Products for implementing operating models, managing workflows, and viewing reports (like Dragonboat for ProductOps) have been built the same way for 20+ years. 'Modern' tools are designed with a roughly similar approach to tools built decades ago. Not much has changed.

This has resulted in rigid, table-based tools with mountains of tech debt providing increasingly diluted and deteriorating experiences for end users.

The worst part? They’re expensive!

how do we know there's a better way? Because we built one of these tools. In 2013, we founded AgileCraft, the market-leading Scaled Agile tool acquired by Atlassian in 2019 (and renamed to Jira Align)

We built AgileCraft in 2013 in the same way tools like Dragonboat are built today - linearly, with one object after another, one feature after another, and one report after another. That's the status quo.

Unfortunately, over time, this creates a problem:

• New features become diluted (decent for everyone, best for no one). You’re forced to grow into bigger, more generic markets and leave your early customers behind.
• Customers never see their feature requests. New features inevitably become diluted (decent for everyone, best for no one) and you’re at the mercy of a product team or CEO for your new features - which becomes a leverage game. Only the biggest customers get attention.
• Your tech debt eats you alive and you slow down. Adding new things to the system means you must touch major parts of the existing system. It’s increasingly expensive and risky to add new features
• New models always replace old ones, and the tools get thrown out with them. Everything comes in and out of popularity. What’s status quo today will be old news tomorrow. For us, that was Scaled Agile and we had difficulty adapting to both the evolution of SAFe (per the issues above) as well as new market dynamics. As ways of working change, existing tools struggle to keep up and they’re costly to replace.

We deeply felt every one of these pains - for ourselves and our customers.

That's why we built Dotwork...

Dotwork is a new kind of platform.

We believe all of these tools are largely comprised of the same general parts, so we built a next-generation platform that abstracts these parts into primitive building blocks - Lego pieces that create powerful solutions.

That means we can configure Dotwork to meet the needs of ProductOps or Product Portfolio Management, essentially ‘cloning’ a tool like Dragonboat.

But we believe that only gets us 80% of the way there - because every organization is different.

Every organization has a level of complexity that can’t be matched by static, generic tools. Every organization has thoughtful people designing, testing, and integrating new ways of working into their teams. Every organization has a strategic advantage in the way they operate differently.

So we built a platform to handle the last 20% - creating a dedicated experience for your organization. Custom, deeply integrated solutions for how you work today and in the future.

We call it a perennial platform because it’s built to adapt to you and grow with you through the various seasons of your business.

How does it work?

The best way to illustrate this is to approach an operating model like Product Portfolio Management by cloning a tool like Dragonboat.

It took years for Dragonboat to build the offering they have today. We can do just as much, and more, with a few days of configuration. Imagine what we could do for your organization.

Representing our organization in the tool

Let’s imagine we’re a financial services company called ‘Cambrian’ - and Cambrian is a multi-product company, so within the Cambrian Portfolio, we have multiple products owned by individual product managers. We’ll say there’s a Personal Finance product, a Credit Card product, and an Investing Product (Remember, this is a configuration, so we might actually call these Product Lines and have Products underneath that)

In Dragonboat, the only way I could get different views for my Portfolio vs Products was to rename the ‘Roadmap’ field to ‘Portfolio’ and the ‘Sub-roadmap’ field to ‘Product’.

Here’s what I get:

In Dotwork, I’m able to set up ‘Portfolios’ and ‘Products’ as explicit things - not renaming fields (and I don’t have to stop there - I could have Product Lines, Departments, Business Units, etc…).

After configuring the Dotwork ‘Ontology’ to match what I created in Dragonboat for Cambrian, this is what we see:

I get a dedicated space for my Portfolio and my Products.

Even better, I can control which objects are configured for my Products vs my Portfolio - for example, I may only want Investment Themes at the Portfolio level and Team Objectives at the Product level.

These will act as our dedicated Roadmaps as well (e.g. we’ll have a Portfolio Roadmap for Cambrian and Product Roadmaps for Personal Finance, Credit Card, etc…)

We can think of these as ‘data rooms’, so our product leaders across these products can set their space up as they see fit or we just generate them from a template for consistency.

This is ultimately the ‘home rooms’ for the areas of the business we own - later on, we’ll be building out our interactive views and reports here as well.

Now let’s set up objects for each of those spaces

In Dragonboat, there’s an implicit ‘level’ to some of these objects, so I went ahead and separated objects that may be more appropriate at the Portfolio level vs the Product level. In Dragonboat, this is all mixed together, but it feels better to separate them this way.

I renamed some things in Dragonboat to play around with this flexibility - for example, having ‘Portfolio Goals’ and ‘Team Objectives’

Unfortunately, there’s no organizational separation in Dragonboat

In Dotwork, we can configure objects to be unique per space while maintaining our ability to roll things up for reporting.

Objects can still relate to each other across spaces, so we’ll see that ‘Requests’ could be children of ‘Initiatives’, while similarly ‘Team Objectives’ could be nested into ‘Portfolio Goals’

Again, as a reminder, we configured these objects to match Dragonboat’s model, but these can be named, related, and extended in any way would want.

So our final model looks like this:

At the Portfolio level, we have:

• Documents: Dragonboat doesn’t have docs, but we love docs for artifacts (like various plans, 6-pagers, strategy docs, etc…) so we included them
• Initiatives: Doffers this as a roadmap item out of the box that seems to be a parent to ‘Ideas’. We included Ideas at the product level
• Investment Themes: Dragonboat treats this as a field, but we like to promote it to a full-blown object so we can see everything in Dotwork connecting back to these key Investment Themes. If it’s just a field, you can only cut data, not drill-in; but as an object, we can do both
• Portfolio Goals: This one is pretty straightforward, but we felt it was too one-dimensional in Dragonboat, so we included Team Objectives at the team level as well (this is optional, we just felt it would give us more flexibility with reporting)
• Metrics: Metrics are a core piece of the Dotwork platform, but they seem to be an afterthought in Dragonboat. Not only will we be able to set up metrics at the Portfolio and Product levels, but we’ll be able to connect them to any external system we want. And more importantly, once they’re in Dotwork, they’re trending from day one - even if they aren’t trending in their source system, like a spreadsheet.
• Decisions: At Dotwork, we love to think about decisions as explicit objects, so we’re adding them. A strong Product Strategy, effective Product Operations, and Product Portfolios that make tough choices on where to expend focus create an environment for better, faster decision making. We believe this is missing from tools today.
• Customers: This is a core tenet of Dragonboat’s model and a primary dimension used in reporting so we’ll have customers here at the Portfolio level and the team level.

And at the Product level, we have:

• Requests: These are quite generic in Dragonboat, but for this example, we’ll think about them as feature requests from customers - therefore, they’ll be contextual to a specific Product.
• Team Objectives: When implementing OKRs, Dragonboat recommends creating team objectives under Portfolio Goals, so we’ve added them here.
• Ideas:

And we’re including Documents, Metrics, Decisions, and Customers again at this level.

Great! That took a few minutes! Let’s move on…

What we get for free with the Dotwork Platform

Now that we have the data model replicated, we can build on our newly minted schema, but before we start replicating some views and reports, there's a few things that we get straight out of the box!

Lists and Boards

For every object we create in Dotwork, we'll immediately have a powerful list view, board view, pivot view, and soon we'll have a 'timeline' view.

The list view can be grouped, filtered, and sorted across any properties you define on the objects:

The board view is a series of drag & drop columns - by default, this works great with statuses, but you can configure the columns to use any property you want on the objects:

Trend anything

A nifty thing in Dotwork is that everything is trending once it lives in Dotwork (or is integrated into Dotwork). This is particularly interesting if we want to pull from third-party tools, databases, or spreadsheets - which are notoriously terrible at storing historical data.

Dotwork stores all historical data and makes it easy to pull into views and reports down the road.

That means a view like this is not reliant on manual updates - anyone in Dotwork can pull from a central repository of live metrics from any API:

Every field in Dotwork keeps its own historical records as well. All status updates and numeric changes have trend data just one click away.

Document Experience

Let’s face it, knowledge work is not translated best through data entry - it’s writing. That’s why the document experience is foundational to Dotwork. Every object is a doc.

There’s no limit to the custom fields we can configure to make every object feel unique, but more often than not, a doc is all you need.

What’s great about this combination of a doc experience with dedicated object types is getting the best of both worlds. Knowledge base tools are typically terrible at structuring any kind of data model for complex reporting (e.g. Notion and Confluence) yet tools that can deliver on complex reporting feel like data entry forms (Jira, Asana, Productboard)

What’s worse is when tools separate object experiences and doc experiences (ClickUp).

They’re meant to be combined.

Relationships

And finally, relationships.

If you’re going to ‘connect the dots’, you better be good at ‘dots’ and ‘connecting’.

All tools on the market today struggle with this, so it’s not a surprise that Dragonboat is no different. These challenges are tough to spot in a demo, but they quickly become issues as tools are used in the wild, especially at scale.

• Relationships are pre-defined: Relationships are limited to the opinions of the platform. For example: This has a parent/child relationship to that, this thing can block that thing, these are one-to-many, that’s many-to-many. In short, any new ‘relationship’ or change to relationship logic is essentially a feature request to the vendor.
• Relationships are difficult to query: Views and reporting have to be purpose-built on top of those relationships, and multi-level reporting (traversing the relationships) is difficult. You can see this in Dragonboat’s prescriptive ‘three-level’ tree. Why can’t you go four levels? Why can’t you change the relationship defined between levels to not be a ‘nested’ parent/child relationship?
• Relationships are difficult to change: The reason tools like Dragonboat have a set approach to objects and sub-objects (you can change their names, not their relationship) is because dynamically changing these structures are incredibly ‘expensive’ to the system. These relationships are either direct relationships on the objects (a column referencing another column on a table) or they exist in a dedicated relationships table. If you want to make a change down the road (for example, I want Project to now parent my Epics) you can’t do this without a ‘migration’.

Dotwork was built on relationships. Our graph is purpose-built to handle these challenges. It’s built for scale, change, and flexibility.

Here’s a simple query in Dotwork to get a user in the system and everything related to her with some second-order relationships:

Roadmaps & Reporting

Now that we’ve set up the Dotwork Ontology (and got quite a few powerful views and features for free), we’ll move on to generating a few key views and reports.

For Roadmaps, Dragonboat has two types of views - a pivot view and a timeline view. They break these views out into different variations, but essentially, those are the two types.

Here’s what they look like in Dragonboat:

Roadmap Pivot View

What we want out of a view like this is the ability to toggle the properties we segment by column and by row. In Dragonboat, we can use the set model we started with - or change the name of existing things.

In Dotwork, we can use any field to segment by row or column. Here we’re copying the screenshot by showing ‘Portfolio Goals’ and ‘Timeframes’.

But in Dotwork, we may want to group by custom fields like ‘Priority’, ‘Now/Next/Later’, ‘Customer Journey’, or ‘Foo’. That’s fine! We can use Objects, Spaces, Fields, Teams, Timeframes, and even Relationships as our segments.

Roadmap Timeline View

For the timeline view, Dragonboat breaks these two views out into a Gantt-style view and a Swimlane view.

At the moment, we don’t have a good Gantt-style view and for the purpose of this clone, I didn’t want to start on something that would take me more than a couple of days to configure/build - but we do have a grouped timeline view that’s quite slick!

This one is very close to the roadmap view in Dragonboat. Still, we currently only support a single level of grouping (granted, I could stack these timelines with different parent filters to get a similar effect). Adding an extra grouping level here isn’t impossible, but again, it would probably take a couple of weeks.

Close enough! 🙂

Okay, time check. We’re still only a couple of hours of work into ‘day one’, but now we’re getting into some views and reports that we may have to do a little custom building for.

RICE Scoring

Products often tout different scoring methods (like RICE, MoSCoW, MoAR, WSJF, etc…) as core features, but in reality, they’re all just the same ingredients - they’re a series of field selections on an object that come together to calculate a score.

Here’s what RICE scoring looks like in Dragonboat:

From what I can tell, we can only set a RICE score on ‘Roadmap Items’, nothing else.

And what if I don’t want to do RICE or MoAR? What if I want my own? Or what if I want to tweak the weights and scoring methodology? RICE might be popular now, but what will be ‘best practice’ in a few years?

In Dotwork, we have this configured as fields that feed a calculated field for the score output. You can change it tweak it, and even roll your own scoring method based on any data in Dotwork - meaning you could have scoring methodologies on your Goals or different methodologies for different Products.

Here’s what a list view looks like with RICE scoring configured for ‘Features’:

Given a bit more time, I’d probably make the selections in the columns different (for example, I like star selections or maybe even sliders for some of these)

Reports

Lastly, we’ll take a few of the key reports we see in Dragonboat and replicate them.

In the first one, it seems we have a ‘Portfolio Delivery Dashboard’ that renders a few different static charts - Epics by Product, Product Goals by Product, Planning Stage by Product, and Portfolio Health by Product.

Here’s what we see in Dragonboat:

And here are the replicated reports in Dotwork:

Second, we have this abstract report that’s represented in some of Dragonboat’s content, but I wasn’t able to find the live version in the product - it may be something that’s sold as an upsell.

Regardless, looking at this view we can get a sense of what we’re trying to visualize here - grouping ‘objects’ (in this case, Requests) by various clusters (Tags in this case).

Here’s what it looks like:

So we made a version of this with a few tweaks.

It’s fine to color by cluster across a single object (like Requests), but we wanted to see if we could handle multiple object types while still getting a sense for the size of the cluster along with visualizing concentrations of different types of objects - and even understand which objects are relatively more ‘filling’ within their cluster (e.g. by effort or value).

I think we were able to achieve this by coloring the objects instead of the categories - because you still get a sense of where the larger clusters are and you can easily look for the bigger or smaller clusters and hover to quickly understand what the cluster is - which feels like a good tradeoff.

Here’s what it looks like.

And obviously the interaction on hover is a big deal here to see what the clusters are:

Now we not only have a relative visual indicator for individual objects taking up more/less space (e.g. one request is significantly bigger than the others), but if we’re looking at multiple objects, we can also visualize the ‘type’ of proposed work by color/icon. For example, we might see that one category has significantly more defects and tickets than customer requests or ideas - which might mean we’re struggling to do anything more than support that category of work, whereas another category consisting mostly of ‘ideas’ might be more green field work.

Final time check - we’re clocking this in at just about three days!

Bespoke Solutions with the Platform Approach

Organizations are snowflakes. Especially in the ways they develop, plan, and execute strategy. More importantly, they’re different today than they were just a few years ago. “Change is the only constant”.

And yet, we build static solutions for moving targets, we dilute our solutions with feature bloat to essentially do less for more people, and we treat organizations as predictable systems.

Solutions should be designed to mold to organizations as complex adaptive systems and solve the ‘perennial’ problem - the ability to weather the organizational changing of seasons.

• As organizations adapt, can their tools adapt with them?
• As organizations differ, can the solution solve specific, novel problems unique to their business?
• As people come and go, can the organizational memory remain intact?

We believe adaptive tools are the future.

We believe that software should be lasting, solve unique problems, and be highly contextual.

If that resonates with you, then you probably feel like the tools of today never quite solve the problem. We’d love to hear you! And if you're interested in working with us to make your own dream strategy view come to life, apply for the design partnership!

‍