Plan for 2023 (as of March 2023)

rufuspollock
anu

Plan for 2023 (as of March 2023)

This started out as a plan for our "product" work. It has become an overall business plan for 2023 covering what we build and offer. It answers the question:

What should we focus on in 2023 and what is the plan of work?

  • What do we do: i.e. make and offer?

    • Terminology: domains (kinds of stuff), stacks (what we make), offers (what we sell)
    • 3 Domains (portals, datahub, data servies), 2 Stacks (portals, datahub) and 5 Offers (portals saas, portaljs, custom portals, datahub and data services)

  • What is our focus? (in terms of new effort) Portals Domain and especially Portals SaaS.

  • What is the plan of work per domain? (Technical and BizDev)

  • Intro

  • Cohere 1 minute intro and summary

  • Start with definitions

  • Tech stack for portals area

  • Roadmaps per domain or per offer

  • Refactor to organize by domain

Changelog

One Minute Version

Terminology

This document is about the kind of stuff we make and sell. The following definitions make discussion clearer.

  • Stacks 📚 vs offers 🛒: stacks are stuff we "make", offers are stuff we "sell".
  • Domains 🪣: categories for the kinds of stuff we make and sell. We'll distinguish three domains:
    • 🌀 Portals
    • 📦 DataHub (Next)
    • 🛎️ Data Services.
  • Offers fall into two classes: products and services.
    • 🍎 Products are standardized in terms of features, pricing etc. Like an apple at a store.
    • ✂️ Services are bespoke and vary from client to client like a haircut.
  • 🚩 when we use the term Product it is a product offer. Product is an overused term. Going forward, reserve product for this specific case at least internally.

What we make and offer in a nutshell: domains, stacks, offers

Three domains: DataHub, Portals and Data Services

Our work falls into three domains:

  • DataHub: easy publishing for data and data-rich content. For power data users e.g. data engineers, data scientists etc.
  • Portals: for data management solutions like portals, catalogs etc. For businesses, IGOs, NGOS etc.
  • Data Services: like data engineering and data analysis and visualization

Offers: Three Products, Two Services

We offer three products, two of which are SaaS. All build on what we already have:

  • Open Data Portal (SaaS): a hosted turnkey SaaS open data portal for governments, cities, NGOs, IGOs etc.
  • DataHub "Next": easy publishing and sharing for data and data-rich content. For power data users e.g. data engineers, data scientists, data geeks etc.
  • PortalJS: an open source framework for building data portals and data management systems

We offer the following services:

  • Bespoke data portals both for open data portals and internal data management and discovery. This includes our CKAN development and CKAN hosting.
  • Data Services such as data engineering and presentation

Two Stacks: Portals and DataHub

This work will be underpinned by two stacks:

  • Portals Stack which is our framework for building data portals using PortalJS and CKAN (and more). It has a sub-stack:
    • Stack 1.1: Portals SaaS Stack which has a specific configuration of Portals Stack to provide a standardized SaaS data portal plus UI for signup and billing.
  • DataHub (Next) Stack: the code for DataHub Next.

Branding

For marketing purposes, recommend presenting products using the DataHub brand and website for consistency and traffic e.g. DataHub Open Data Portal at datahub.io/open-data-portal/ and simple DataHub (Next) with datahub.io.

For services we recommend using the Datopian brand and website.

We emphasize that, of course, we can cross-present if that is useful for discovery and SEO.

Fuller version

What and Why Summary

We address four overlapping but distinct user needs

I want a data portal

Quickly, reliabily build elegant data portal sites (based on CKAN or another backend). Portal in broad sense that includes open data portals and internal data catalogs.

  • standard solution, right now ⟹ Data Portal Cloud SaaS (or on premise)
  • tailor-made ⟹ get bespoke solution
  • get a framework ⟹ get PortalJS

I want data cleaned up / processed / presented

⟹ I want data services e.g. data engineering, data visualization etc …

I want to publish / share data with a community

⟹ I want a (public) DataHub and active community

I want a framework for building data portals

⟹ I want a framework and a team who know how to use it

I want a framework for building data management solutions

⟹ I want a framework and a team who know how to use it

🚩 we are not so sure this is a need we address right now. Clearly, a general demand but perhaps too general.

Our products reflect our core expertise

NB: DataHub is hyper-focused on being a standardized product. It incorporates a lot of learnings from our past decade plus. Has a specific approach and niche.

Roadmap

Objectives and Key Results

Open Data Portal SaaS: sales

  • Marketing
    • 5 key partners are aware of the offer
    • and 2 have given feedback.
    • Reseller terms worked out.
    • Info in relevant locations (even just one announce post on medium, linkedin, … also g2, etc)
  • Funnel
    • 1 inquiry a week by May 2023
    • 2 inquiry a week by Sep 2023
    • 1 sale a month
  • Compelling offer
    • Functional landing page
    • Pricing
    • Feature list (improved)
    • Video demo (perhaps after registering interest)
    • Request trial/access => We'll follow up (White glove onboarding (?))

DataHub Next

  • MVP working by May 2023
  • Invite only user approach
  • 100 signups, waitlist of 500

Portals Stack

  • All delivery team aware of terminology and existence
  • Creation of knoweldgebase
  • ? consolidation of materials

PortalJS Offer

See ../areas/portaljs#Objectives and Key Results

Recommendations

Focus development energy on (in rough order):

  • DataHub Next
  • Open Data Portal SaaS
  • Portals Stack documentation and scaffolding to improve team efficiency and path from stack to a beespoke site.
    • Open-source more clearly as PortalJS

Focus marketing energy on:

  • Open Data Portal SaaS: build a pipeline (use in RFPs?)
  • Data Engineering services: creating new channels e.g. upwork, clutch.co etc
  • (?) CKAN oriented SEO (?) outside of ckan.org (??)

Marketing work should be focused on:

  • In funnel: Improving quality and credibility of evaluation experience e.g.
    • our website
    • get in touch
    • our case studies etc
  • Growing the funnel: getting attention in channels that matter … e.g.
    • Publishing on places where audience already is
    • Going to events where audience already is
    • NOT (or very limited): content marketing
  • Branding: use one name. Either Datopian X or DataHub X . Recommend DataHub because of site traffic etc. Then consolidate products under DataHub brand name and site wherever possible

Naming

  • Naming: stacks and offers (internal). Externally we will probably still use products for offers/solutions.
  • PortalJS: use this for "all" the frontend stuff in the DMS platform.

Status

  • Open Data Portal SaaS: 80% but more than good enough to demo and offer. As we get demand we will need to work on publish UI and management
    • Landing page: complete but more to do e.g. pricing, CTA etc.
    • Marketing: just started.
    • Development: signup, billing etc plus improvements to demo.
  • DataHub Next: 50% of an Alpha. Actively working on completion with target for end of March.
    • Marketing: none for now. will probably want to go via word of mouth within a community. "register for early access"
  • PortalJS: existing, solid base. Primarily about consolidating material there.

Stacks

Portals Stack

What is it?

A common platform of components, tools etc with which you can rapidly build data management solutions including data portals, data catalogs and more.

What is it now?

  • Standardized modern stack of Portal.JS + CKAN (+ other components) for building more powerful, elegant, useable data portals faster
  • Able to still use CKAN to benefit from battle tested backend, installed base, name recognition etc

Full vision: what we describe on datahub.io/enterprise atm. Or what is documented on datahub.io/docs/dms

Components

  • PortalJS
  • CKAN
  • Data API
  • Tooling and Docs for rapidly scaffolding new solutions e.g. custom data portal
    • Knowledgebase
    • Scaffolding

../Excalidraw/portals-stack-2023-03-21.excalidraw.svg

Why do we want it

What are the needs we have for our product and for clients?

  • Quickly and reliably build bespoke open data portal sites (based on CKAN or another backend)
  • Supports pure SaaS Data Portal: low price, better margins, recurring revenue, no to low maintenance
  • Bid on custom "DMS" solutions and applications (DMS covers portal, publishing, catalog etc) ⟹ Have a DMS framework offer so that we can reference in bids for custom
  • Gain new data services work
    • Bid on data engineering work
      • Have a good price point ⟹ having a framework (is beneficial)
      • Have compelling and credible material re delivery
        • previous projects
        • a framework you can deliver with
    • Deliver that work effectively

Actions

Regarding this platform there are the following actions

  • Create offerings
  • Improve documentation: consolidate DMS documentation
  • Centralize in one location
  • Advertise the platform itself? DataHub DMS (or DataOS, Framework)

DataHub Next

Developing a distinct prototype platform (DataHub Next).

See Offers for more.

Offers

Open Data Portal

SaaS open data publishing solution for cities, governments, IGOs and nonprofits who want an open data portal (with minimal customization). Attractive, easy, cost-effective, turnkey.

🔗 https://datahub.io/ (currently on landing page)

Why?

Open Data Portal product already mostly exists, has a proven market and we already have sales and sales channels.

  • Have a mature portaljs+CKAN based solution
  • Clear potential market for open data portals (1000s of instances)
  • Have customers in this area
  • Have existing sales channels such as via ckan.org or RFPs
  • Know other channels we could develop
  • Opens up a new market by having a turnkey product at an attractive price point. (We have evidence from calls of people thinking that CKAN and CKAN hosting is expensive – and it currently often is).

DataHub Next

🔗 https://datahub.io/notes/plan

🚩 exact MVP focus still under discussion. See datahub-next-direction-march-2023

Why DataHub Next?

  • We want to try and have a highly standardized product play for easy publishing of data and data-rich content
  • We think there is a market gap for something which is:
    • consumer oriented
    • built around git(hub)
    • simplified and easy to use (rather than heavy duty)
    • takes this different perspective: start with the README, start with a scratchpad
      • data-rich content centric rather than dataset centric
      • think better to expand from here … than start from the data heavy perspective
  • To have an alternative Stack to Portals which is currently dependent on CKAN which has significant limitations as a backend. Good to explore an alternative that could takeover depending on how Portals Stack goes.

PortalJS

A open source framework for building data platforms such as data portals, data catalogs, data lakes and data management systems. Open source, mature, fully-featured and production ready. Trusted by governments, startups, nonprofits and the Fortune 500.

Why offer PortalJS? RFPs and marketing

  • Because we can point to this in RFPs
  • Point partners to it
  • Form of advertising
  • New channel to Datopian and our offers

Appendix

Questions (TODO)

  • Do we offer the PortalJS externally? (Does it matter right now??) ✅2023-03-21 yes we will offer it externally
  • What is DataHub Next exactly - see datahub-next-direction-march-2023
  • Why pursue DataHub Next at all? See above.
  • Do we use "Next"? Is it confusing (next of what)

What's been confusing and what we do about it

As you can see in the diagram we have had several things overlapping. This has caused confusion.

  • "Products" and Services overlap. We often used the product vs service distinction. But think that domains is more useful.
  • What's confusing is some "products" are used to build other products/solutions.
    • Internal frameworks that are also offers e.g. Portals Framework is also PortalJS (and didn't even have a clear name before)
    • Internal frameworks that help build other sort-of frameworks that power offers e.g. Portals Framework creating the Data Portal SaaS Framework to power Data Portal SaaS
  • Another reason this is an issue: We don't have an internal term for the overall stack/toolkit/framework we use to build portals stuff atm. Best would CKAN+PortalJS+…

Going forward:

  • Let's focus on what is most useful for clients. I'm not sure they think about product/service distinction. Bucket and especially need more appropriate.
    • For DataHub not even relevant. It's just about DataHb
    • For Datopian can be Data Services and Data Portals
  • For Datopian e.g. on upwork and datopian.com we can focus on services e.g. our github profile can focus on this, our upwork profile etc (though still fine to include other items and especially our ckan offer as that is link from)

Insights:

  • easier to start from the underlying "platforms" we are building

Product is an overloaded term

Product is an overloaded and hence ambiguous term that mean different things in a variety of different contexts:

  • Off-the-shelfness vs customizability: e.g. NextJS is a framework, Firefox is a product. Product: a standard thing you can buy "off the shelf" and any customization is built into the product the user can alter themselves like preferences in Firefox or font-sizes in an editor.
  • Products vs services: a product is something you can sell again and again e.g. a razor whereas as a service is specific to a client e.g. a haircut.
  • Something offered (a product) vs something internal (a tool) e.g. people say X has product-market fit. For example, you could say NextJS has reached product market fit even though in first sense it is not a product.
  • Something you sell for vs something you don't
  • (Relatedly) External vs internal: products could just be any defined software artifact internal or external e.g. here is the latest version of our product (aka tool) for building websites for clients. Or product is just for things you offer externally.

To take an example of our case: does our product plan cover the development of PortalJS even if we don't directly sell or offer PortalJS to customers? Or is product just for specific offers to clients that are standardized e.g. a standardized data portal hosting app?

We address this ambiguity by avoiding use of product and using Stack and Offer.

More in product-terminology

Terminology (consolidated)

  • Stack (rather than Framework or Platform)
  • Offer (rather than Solution)
  • PortalJS Framework (rather than DMS, DataOS etc)
  • PortalJS? A javascript framework for building data portal frontends in a headless style and especially using CKAN as the backend (so-called Hybrid CKAN). https://github.com/datopian/portal.js
  • What is headless DMS approach? aka JADStack?
  • DataHub v2: an alternative stack developed in 2015-2017 that powered DataHub.io from 2016 to the present. DataHub v2 is now deprecated and will be replaced by DataHub Next. See https://tech.datopian.com/datahub/developers/
  • What about DataHub v3 at https://tech.datopian.com/datahub/v3/ This is now deprecated but this evolved in late 2021/2022 into what we now call DataHub Next Stack

Deprecated or Obsolete or Invalid Products

  • Enterprise Data Catalog: enterprise data catalog targeted at enterprises who want an internal data management catalog and data management system. ⏸️ Put this on back-burner: can keep offer live to see who bites. But not a priority. Why? Don't really have the features. Don't see demand conversion yet (i.e. actual sales). For more detail see ../projects/datahub.io-design-sprint-2023#Product: DataHub.io aka DataHub Cloud
  • DataHub Marketplace: Data marketplace with easy transactions to buy data. 💤 nice to do someday and may re-emerge out of DataHub Next.
  • DataHub Pages: Like github pages for data: publish your content and data as its own individual site quickly as possible. ⛔ Barely got to v0.1 in March 2022. Much of it now covered with Flowershow and DataHub Next.
  • Flowershow: a tool to build DataHub Pages and NextJS stuff. Not really justified as a product in itself atm. ❓🚚 needs a cloud service to have a revenue stream and will probably MERGE into DataHub Next b/c natural convergence and cloud service there.

Note about Portals Stack "Product" supporting services

Commentary re services work: actually our services work is often hybrid:

  • Pure services: we do some bespoke custom development around a standard tool or from the ground up. Example: Birch
  • Hybrid services: most of our CKAN or bespoke portal world.

Connections of the two buckets

NB: Whilst described as distinct there is some connection and overlap:

  • Potential overlap in components e.g. Data Table or Charting components
  • Definitely shared learnings and insights e.g. even if have separate Data Table etc likely very similar
  • Scratch will prototype a major module "Canvas or Stories" that we probably want to bring over into DMS
  • As Scratch develops could be that we want to increasingly use this and focus on this

Drawing presentation of whole thesis (partial) 🚩 may be a bit out of date now

© 2024 All rights reservedBuilt with DataHub Cloud

Built with DataHub CloudDataHub Cloud