Drupal Starshot product strategy v1.0

This is really good. Perhaps could include 'publishing workflows' and 'Site search' to the list of recipes in the 'What capabilities must we have?' section.

A little bit of early feedback. I think the competitor list needs review. Leaving out the enterprise competitors, I was surprised to see Squarespace omitted given that Wix is included. I think Umbraco should be included at this level. WooCommere and Elementor likely merit inclusion as part of the WordPress family.

@tonypaulbarker small clarification, we specified Wix Studio rather than Wix itself, as it is aimed at slightly larger projects. We didn't think that Squarespace projects were quite in the budget range that we are targeting. But in your experience, are you seeing such projects?

🩵 I love that one will need to write less code to use Drupal.

AI-powered tools that simplify creating content types, Drupal Views, and other site elements for everyone

Drupal site building features are quite simple already, and now more simple when ever.
But if someone is learning Drupal for the first time, maybe some things like "views arguments" or "views relationships" could be explained by AI or helped with.

Competing no-code solutions today enables to generate websites quick from answering few AI's questions. Maybe various AI experiments of automating site building (already in development by multiple people), can also help to generate websites quick to compete with this.

Also, emerging Drupal AI capabilities will help marketers in many other ways beyond (some examples https://workflows-of-ai.com/)

web designers to build and manage websites independently, without relying on developers

Include "Site builders without relying on web designers" in the strategy? Because design is difficult, more difficult when coding (especially coding with AI help).

Improve the ability to create themes and templates

There should be a lot more themes to choose from in the project browser. This is huuge pain point. "Experience builder" will address some of this problem, but themes are still quite non existant in Drupal.

One idea is to showcase "Sub-themes that depend on this theme" like I described more here #3241544-7: Add filter by project dependencies (ecosystem) → making themes more extendable, dicoverable, used and maybe encouraging people to share their sub-themes.

@pameeela thanks for the clarification.

I haven't seen Squarespace and I haven't seen Wix Studio or many of the others mentioned in an RFP. WP and Umbraco along with Drupal would be much more common in the UK market. But - it depends a little on what we are including in the figure. I think the scenario for a quickly launched conference website could easily fall into a lower budget range. If that budget - I think we should clarify too whether that number is for year 1 - includes some things like design, marketing input, content creation, photography, SEO support and so on then it can exceed the lower end of the budget for start ups no matter the technology choice. Small agencies that are focussed on branding and design rather than engineering are an example where the cost of the technology platform and hosting might be a smaller component of the overall budget. Squarespace has quite a large market share so I don't think we should overlook it. See also https://www.squarespace.com/designer/home

I think these design focussed small agencies could adopt Starshot where currently there are barriers to being able to select Drupal Core.

Hope this helps!

A couple of comments, responding to both the blog post and the document, because they don't entirely match up.

1. The language in the blog post is focused exclusively on 'marketers', e.g."Drupal Starshot aims to attract mid-market marketers by offering out-of-the-box marketing best practices" but three out of the four use cases in the document would definitely not describe themselves as marketers:

● A marketer for a tech startup ...
● A web manager at a University who runs a department website...
● A web designer at a small agency is used to working with CMSs ...
● A developer who has experience creating WordPress themes...

The latter three are all 'web developers' - just ones who are a lot more generalist than a 2024 Drupal developer who works at a Drupal agency of 15-30 people.

If the document is for internal use, then it should be understandable by the people who work on Drupal now. And when I see 'marketer' I don't think 'web developer in a university department' because that was my first web job and it consisted mostly of hand editing HTML in vim on production servers (but the person I sat next to in the office whose job I was covering for a year, had been seconded to build a load of wordpress sites for something - this was in 2007-ish). 'Marketer' is not an accurate description of those people's roles unless you argue that any public-facing website is marketing, but then everyone who works on websites would be a 'marketer' and it doesn't differentiate.

In general, I think the target can more accurately be described as 'someone who has to build a website mostly by themselves' which 'ambitious site builder' still works for but 'lone ambitious site builder' or 'low code ambitious site builder' might be more specific.

Empower content creators, marketers, web managers, and web designers to
build and manage websites independently

This points a bit more towards the actual target - people that need to build and manage a website independently - i.e. it focuses more on what we are trying to enable people to do, not just what they supposedly are.

2."without.. having to use the command line" - also from the blog post.

All three, or may all four people described, are likely to be familiar with the command line to the extent they will not be overly fazed by opening it and copy and pasting some commands in. Saying 'without' a priori excludes making UX improvements on the command line (quickstart etc.) which can make people's lives easier.

The PDF doesn't mention the command line at all, so is this something that Dries has just added to the blog post that's not in the product strategy, or is it part of the product strategy that's not in the PDF? It could just be changed to 'without having to be comfortable on the command line' and that would be fine.

3.

Smart defaults out-of-the-box along with recommended best practices for
common marketing tasks, such as SEO, social media sharing, event promotion,
analytics, and newsletter sign-ups

This list feels like it's starting at the end of building a website rather than the beginning.

You can only have a newsletter sign-up if you have a newsletter. Assuming you want Drupal to send the newsletter (and if you don't, then a single newsletter sign-up is going to be hard to provide because it would have to integrate with a completely separate subscription database) then you need to:
1. Be able to send HTML e-mails
2. Be able to generate the content of those emails from Drupal content

Sending HTML e-mails and generating the content of those e-mails are both non-trivial tasks with Drupal that recipes, more opinionated module selection, and improved documentation (e.g. simplenews project page mentions poormanscron which hasn't existed since Drupal 6) would all help with, they are fundamental barriers that people hit.

This is somewhat covered by:

Advanced content modeling and governance features
○ Efficient content reuse across multiple channels, enabling marketers to scale
your reach without duplicating efforts

But it's not clear why these are in two different bullets and disjointed from each other.

For the product strategy to actually work, then the different recipes need to be coherent and work with each other - building on top of each other as opposed to incorporating competing modules or approaches. I think this needs to be more explicitly stated and baked in.

4. Target organisations:
"Small businesses often served by freelancers and small agencies" - shouldn't this be 'freelancers and small agencies often serving small businesses'?

three out of the four use cases in the document would definitely not describe themselves as marketers

I liked the marketer focus, because it is simple and most common. And even if I am not a marketer, I would like Drupal to be as simple to use, as if I was one.
If Drupal is simple for marketers, it is simple for everyone and all benefit.

Another part of equation is not only simple, but flexible, enabling 'ambitious site builders'.

@catch you have some great points and highlighted some areas of the strategy that we definitely can improve!

We agree that the "marketer" persona very ambiguous, and need to clarify it. I think it is a convenient shorthand but we are working on some more specific language and descriptions. We should add this into the strategy itself once we have it.

This list feels like it's starting at the end of building a website rather than the beginning.

This is true but is also somewhat by design. The "marketer" that we have in mind is someone who works in the web space and understands the digital ecosystem, and in many cases probably already has a brand, and even an existing website. When assessing Drupal, they will expect to understand/test its capabilities in these areas.

When it comes to newsletters specifically, I think our focus will have to be offering easy integration with best-in-class tools, rather than trying to provide this capability in Drupal. We need to do more research on this, but should probably update the strategy to make this more clear.

a single newsletter sign-up is going to be hard to provide because it would have to integrate with a completely separate subscription database

I agree it will be hard, but not as hard as trying to build the capability in Drupal? Speaking for myself only, this helps to encapsulate the market space we are aiming for (and why it does not include Squarepspace directly). Squarespace has a native newsletter tool as a paid add-on. It's fine, and convenient since it's fully integrated, but it's not great. So the way I'm thinking of it is: if you like Squarespace and are happy to use all its native tools, then you're probably not a good candidate for Starshot. But if you find it's too limited or start to outgrow it, and you need to use third-party tools anyway for things like your newsletter, you might consider moving to a more robust platform like Starshot.

Re: command line, I can't say I have had the same experience with folks I have known in that role being comfortable using it. But maybe this also needs research. Do you think making UX improvements to the command line could be part of the Drupal core strategy instead?

I agree [integration with 3rd party newsletters] will be hard, but not as hard as trying to build the capability in Drupal?

Well there is https://www.drupal.org/project/simplenews → , I haven't personally needed to use it, but it's well established. But this conversation is why I don't think it's a good example to use in the product strategy because 'newsletter signup' is so ambiguous.

Re: command line, I can't say I have had the same experience with folks I have known in that role being comfortable using it. But maybe this also needs research. Do you think making UX improvements to the command line could be part of the Drupal core strategy instead?

Yes but this is a bit different from what I'm saying.

If the starshot product strategy is that 'a starshot user never has to touch the command line' then it potentially means adding a tonne of complexity. For example it has taken about ten years for automatic updates and project browser to be anywhere near production ready, and they are primarily so people don't need to use composer on the command line to download and update projects.

If the product strategy is 'we will minimize reliance on the command line for starshot users' then it doesn't preclude replacing any particular command line task with a UI or some kind of hosted solution, but it doesn't require from the outset doing that for every single one up front.

Moving to Drupal CMS!