Schema Design | Jobs to be Done

[j12y]

The way I'm thinking about the Tools Catalog is that there are Jobs to Be Done by a DevRel practitioner. Tools exist to accomplish some of those jobs. Rather than being a straight list, it would be to design a schema that is very workflow based.

The challenge is that a statement like:

When I author blog posts, I want to generate static pages, so I can have a fast website.

is far wordier than "Static Site Generators" as a category with tools listed like Gatsby, Hugo, Jekyll, etc.

Does defining the jobs and responsibilities of somebody in DevRel create a uniform way of thinking about all the tools that are relevant for specific circumstances, or is it unnecessarily complex without adding value. 🤔

If it was a collection of statements the value is a fuller picture of all the tools that might accelerate a devrel job.

When I author blog posts, I want to spell-check, so I have error free content.

• Grammarly, Fiverr, Claude, ChatGPT, etc.

When I author blog posts, I want to generate a header image, so I have a visual to grab attention on social media.

• Canva, Midjourney, etc.

When I author blog posts, I want to allow comments, so I can gather feedback from the community.

• Discourse, Disqus, Commento, Talkyard, etc.

When I author blog posts, I want to use a hosted service, so I can not worry about operations.

• Medium, Dev.to, Hashnode, etc.

When I author blog posts, I want to use the same tool as a non-technical contributor, so we can collaborate on content.

• Wordpress, Drupal, etc.

When I author blog posts, I want to use a headless CMS that supports markdown, so that I can format quickly.

• Sanity, Contentful, etc.

Thoughts?

[j12y]

It seems like I'd want this relationship to be bi-directional, but JSON becomes a less desirable way of creating a specification and data because of this reverse indexing consideration.

tool.json

{
  "name": "foo",
  "website": "https://foo.com",
  "budget": "< 240",
  "jobs": [
     "When I author blog posts..."
  ]
}

job.json

{ 
  "name": "When I author blog posts...",
  "tools": [
      "foo",
      "bar"
  ]
}

Being in a single file would perhaps work by using defs to capture the jobs in a central schema and then defining the tools as data with properties including items from that long list of jobs.

    "$defs": {
        "job-1": {
            "description": "When I foo, I want to bar, so I can baz."
       ...

[j12y]

What if it were more like this:

{
    "name": "",
    "url": "",
    "category": "",
    "jobs": {
        "situations": [],
        "motivations": [],
        "outcomes": []
    },
    "evaluation": {
        "performance": "",
        "price": "",
        "customizability": "",
        "learnability": "",
        "compatibility": ""
    }
}

Each tool would still be an individual data file representing that product. We could then generate output that allows for more clarity on all the tools relevant for a job. The situation, motivation, outcome triple is kept separate which could reduce the repetitiveness at specification.