DEV Community: Rosie Sherry

Strategies to simplify your BDD step definitions

Rosie Sherry — Fri, 08 Nov 2024 17:14:47 +0000

Techniques to boost your efficiency for implementation, writing BDD steps definitions and glue code

by Tamás Balog

If you are a tester, you have probably heard about Behaviour-Driven Development, or BDD in short, and the debates around what it is, and how and what it should be used for. Regardless of what we think about the subject, we cannot deny that test automation tools built to support BDD are with us. They are adopted and used widely in the industry, and they will be with us for some time.

Throughout my testing career, a great portion of my test automation activities involved using some kind of BDD test automation framework. Tools like Cucumber, JBehave and other alternatives. As someone who does coding, I’ve always been interested in refactoring to lessen the amount of boilerplate and duplicate code. This results in improved comprehension and minimising the amount of code. This includes reducing boilerplate code in step definition methods and in glue code overall. Simplifying them. Or getting rid of them entirely if possible.

You may be wondering, “What is glue code?” On one hand, it consists of step definition methods. Ones that tell the BDD automation framework what to execute when it encounters a Given, When or Then step in a Gherkin feature file. Essentially glueing parts of Gherkin plain text files to executable test automation code. On the other hand, it can be hooks. Methods that execute before or after Gherkin Features or Scenarios.

In this article, I’ll present various ways of simplifying glue code and integrating them closer to the language of your automated tests. In the code examples below I’ll use Cucumber and Java code snippets.

Standard Cucumber step definitions

First, to put you into context, let me demonstrate how a regular Cucumber step definition may look like in Java.

Using regular expression as the step pattern:

@When("^user attempts to log in with (.*) username and (.*) password$") void userAttemptsToLogInWith(String username, String password) { }

or using Cucumber expression as the step pattern:

@When("user attempts to log in with {string} username and {string} password") void userAttemptsToLogInWith(String username, String password) { }

The essential parts of this method are:

one of the @Given, @When, @Then, @And, @But annotations placed on the method to signal the type of the step, and make the method be recognised as a step definition,
the step pattern specified in the annotation: this is how Cucumber maps the step in a Gherkin file to this method,
the method arguments that map to the arguments of the Gherkin step.

Now, let’s look into the ways of simplifications and alternate usages.

Java 8 lambda expression-based step definitions

With the introduction of lambda expressions in Java 8, a lot has improved and become simpler. It has brought forth alternative ways of implementing applications. This includes Cucumber as well as introducing a new way of defining step definitions using lambda expressions.

For that, you have to use a different dependency, namely cucumber-java8. Once you have this configured, you have to make the following changes in your step definition classes.

The class must implement the io.cucumber.java8.En interface (or one of its language specific variants). With this change, new step type specific methods (Given(), When(), etc.) become available in your step definition class.

Your current step definition methods (or at least the ones that you want to simplify) have to be converted and moved to the class constructor. So, the following method:

class LoginStepDefs { @When("user attempts to log in with {string} username and {string} password") void userAttemptsToLogInWith(String username, String password) { //login actions } }

would become

class LoginStepDefs implements En { LoginStepDefs() { When("user attempts to log in with {string} username and {string} password", (String username, String password) -> { //login actions }); } }

From a readability point of view:

This form eliminates the void keyword and the entire method name, making the definition more concise, and quicker to implement.
However, although the code is more concise, having several step definitions shoved into the constructor can feel overcrowded and sometimes even more noisy than having them in the old-school method form.

There is some debate on whether the regular method form or the lambda one is better. There are both personal preferences and practical arguments (e.g. dependency injection) put on the table, and there has even been some discussion on replacing Cucumber’s Java8 library with an alternative solution.

Patternless step annotations

The following questions can be made for the step annotations:

Do you actually need to explicitly specify a step pattern?
Is there an alternative to still have it specified?

Years ago, on a previous project, we had a custom test automation solution and test runner that worked somewhat differently from Cucumber and other BDD frameworks. That solution used its own @Given, @When, etc. annotations with one main difference: you didn’t have to specify the pattern in them. Instead you had to phrase the name of the step definition method in the way it would be used in the Gherkin files.

For example:

@Given void userAttemptsToLogInWithXUsernameAndYPasswordOnZ(String username, String password, Server server) { }

You may have noticed the uppercase letters X, Y and Z. They allowed users to parameterise these methods, and it worked as the following:

a regular expression was generated from the method name, where X, Y and Z would be replaced with the (.*) capturing group, like this:

^user attempts to log in with (.*) username and (.*) password on (.*)$

then in a follow-up step, the framework would go through the list of supported parameter type resolvers and perform the following:
- it parsed each argument (the content of each (.*) group) into the corresponding type specified in the method’s argument list,
- then, it injected the resolved values.

This is sort of the opposite way to how Cucumber step definitions work. There, you specify the actual pattern without the method name, while here you specify the method name as a sort of pattern without specifying the actual pattern.

The advantage of this was that you did not have to specify the pattern in the annotation, only in the method name. This resulted in less coding and less noisy code. But, the step annotations still provided an attribute to specify a custom pattern if the default, generated one was not sufficient.

This also made engineers phrase the names of step definition methods in a way they would be used in the Gherkin files, resulting in clearer steps. It also prevented confusion regarding having a step pattern used with a different method name for no proper reason. Like something like the one below would have caused:

@When("user attempts to log in with {string} username and {string} password") void authenticate(String username, String password) { //login actions }

Leverage custom IDE integration

Although, using a custom-developed IDE plugin does not necessarily reduce the amount of test code you have, it can at least help increase the level and easiness of code comprehension.

The idea I’ll demonstrate involves a feature called code folding that is a standard one in many IDEs and text editors. Code folding is when an arbitrary range of text in a document becomes hidden (i.e. collapsible and expandable), and is replaced with a custom placeholder text that lets you know a summary of what is under that folded section.

Such a placeholder text may be as simple as an ellipsis (the … symbol). This is used mostly when the content, for example a method body, is not relevant at the moment, and it just needs to be hidden.

Or, it can be actual contextual information that provides the same or almost the same information that the actual unfolded code provides, but in a simpler way. A good example for this is folding anonymous object instantiation in Java to lambda expression style. So, given the following method:

CredentialsProvider getCredentialsFor(String userType) { return new CredentialsProvider() { @Override public Credentials get() { return credentialsService.get(userType); } }; }

the folded code will look like this:

Now that you’ve seen a few simple examples of code folding, let’s see some ideas on how certain parts of step definition methods may be folded to achieve a better comprehension of them.

Use a step pattern in place of the step definition method’s name

In my experience, when it comes to reading and comprehending a step definition method, people focus on understanding it by reading the step pattern instead of the method name. So why not improve this aspect? Since the method name may be a duplicate of the step pattern, and it cannot be omitted if one uses actual methods, let’s try to make it appear in a more concise way.

This involves two steps. First, fold the step pattern in the step annotation into an ellipsis like this:

This results in a less noisy code, and you still have the information of what type of step (Given, When or Then) this method is for.

Then, if you prefer reading the step pattern, and the step pattern provides more context for the step than the method’s name, you can go one step further. Fold the method name using as placeholder text the step pattern.

If you have the option, you can fold the public and void keywords as well, so you end up with the following method “signature”:

Of course, if you want to, you can go further, or in a completely different direction, with the customization of this folding. This is up to your personal or project preferences.

Dynamic resolution of steps

Let’s say you have steps that have a clear formalisable format. You don’t want to deal with implementing separate step definitions for each of them because it would be an unnecessary duplication.

One thing you can do in this situation, and what we did on a previous project, is using dynamic parsing and resolution of steps. This eliminated the need to implement actual step definition methods for them. We mostly used it to build validation steps for web UI test automation, like the ones below. (Screaming snake case parts reference Selenium WebElements and Bys.)

**Then** the TITLE of the RECOMMENDED_BOOKS module should be "Recommended books"
**Then** the TITLE of the first item of the RECOMMENDED_BOOKS module should be "Atomic Habits"
**Then** the second AUTHOR of the first item of the RECOMMENDED_BOOKS module should be “Noone”

As you may see, it kind of works in a backwards order. If you take the last example:

It locates the Recommended Books module on the page the scenario is currently on. RECOMMENDED_BOOKS here is mapped to a list of WebElements.
It gets the first item from that list, which is the element of an actual book.
It gets the list of AUTHORs as strings. AUTHOR here is mapped to a By object.
Then, it gets the second item from the list of authors.
Finally, it compares the found value to the expected one specified in the ‘should be “Noone”’ part.

All of this was made possible by the implementation of a common parser logic. Once it was put in place, no coding was required to explicitly implement this kind of Gherkin steps. The only coding involved in this area were either bug fixes, improvements to the parser logic or extending the corresponding page objects.

Now, of course one could argue how readable these steps are, or whether they could be replaced with visual testing. But, at that time, it provided a clear structure and format. Customisation of underlying page elements, choosing elements by index, and other goodies too. For us it was a nice way of implementing validation with a minimal amount of coding.

Use frameworks with pre-implemented step libraries

One way of minimising the amount of glue code is getting rid of them entirely. This may be achieved for example by using libraries that provide pre-implemented steps for many common or not so common tasks.

They may also have different templating solutions and expression languages to customise steps and actions with dynamic input data, like various types of request bodies and headers for sending HTTP requests in API tests.

I’m only including brief introductions of some libraries below, just to give you an idea where to begin, then I’ll let you delve into them if you are interested.

Framework	Summary from the framework’s documentation	Scenarios are implemented as ...
Karate	“Karate is the only open-source tool to combine API test-automation, mocks, performance-testing and even UI automation into a single, unified framework. The syntax is language-neutral … in a simple, readable syntax - carefully designed for HTTP, JSON, GraphQL and XML. And you can mix API and UI test-automation within the same test script.”	Gherkin Features with Karate’s own language parser (instead of Cucumbers)
Vividus	“VIVIDUS is a test automation tool that offers already implemented solution for testing of the most popular application types.” This includes database, API (Application Programming Interface) and UI (User Interface) testing as well.	JBehave Stories
Citrus YAKS	“YAKS is a framework to enable Cloud Native BDD testing on Kubernetes! Cloud Native here means that your tests execute as Kubernetes PODs. As a framework YAKS provides a set of predefined Cucumber steps which help you to connect with different messaging transports (Http REST, JMS, Kafka, Knative eventing) and verify message data with assertions on the header and body content.”	Cucumber Gherkin Features

Take scenario development to the code level

Although this approach doesn’t get rid of step definition methods, it simplifies tests from a different, sort of the opposite, perspective of what I introduced in the previous section. Instead of implementing your tests in Gherkin or similar files, and having to bother with step definition implementations, you implement tests as actual code in a Gherkin-like DSL (Domain Specific Language). This way you don’t have to touch any actual Gherkin file. That is what the JGiven framework aims to achieve, or at least how it fits into the topic of this article.

With applying some basic test configuration, and extending some base classes, you can implement “Gherkin” steps and scenarios in regular JUnit, TestNG or Spock test methods. Thus, you also have proper and direct access to the assertion, mocking, etc. libraries that you use, and your test methods would read close to actual Gherkin scenarios with test reports generated accordingly.

The following one is a Given step with a more granular implementation (see the corresponding section in the JGiven documentation):

@Test public void validate_recipe() { given().the().ingredients() .an().egg() .some().milk() .and().the().ingredient("flour"); //other steps… }

Or, if you take a more advanced scenario, the JUnit 5 test method below, it executes a parameterised test with multiple different input data. It essentially simulates the execution of a Gherkin Scenario Outline with a set of input data its Examples table would receive.

This example is from the Parameterized Scenarios section of the JGiven documentation, altered for conciseness and to use the more commonly used JUnit 5 parameterised test approach.

@ParameterizedTest @CsvSource({ "1, 1", "0, 2", "1, 0" }) public void coffee_is_not_served(int coffees, int euros) { given().a_coffee_machine() .and().the_coffee_costs_$_euros(2) .and().there_are_$_coffees_left_in_the_machine(coffees); when().I_insert_$_one_euro_coins(euros) .and().I_press_the_coffee_button(); then().I_should_not_be_served_a_coffee(); }

This test method would generate the following report, so you would still have proper test reports and living documentation that you can share with various stakeholders.

coffees left in the machine When I insert one euor coins And I press the coffee button Then I should nt be served a coffee Underneath it shows a table with the various input data and the status of the test under a header called Cases. The first column shows the ids of the tests as 1, 2 and 3. The rest of the columns read as coffees, euros, Status. The test case rows read: 1 coffees, 1 euros, passed 0 coffees, 2 euros, passed 1 coffees, 0 euros, passed"/>

We can take this example one step further by applying some IDE plugin magic on it. Using custom-developed code to fold in this case, you could bring your test code even closer to how an actual Gherkin scenario would read. Something like this:

coffees left in the machine; When I insert one euro coins And I press the coffee button; Then I should not be served a coffee; }"/>

Please note that this code folding is not from an existing IDE plugin. It was made specifically for this article for demonstration purposes.

Don’t use BDD frameworks at all

Whether you should implement your tests as BDD scenarios and use a test framework that supports that, depends on the project domain and resources, application type and other aspects.

One argument I have heard many times is the fact that glue code adds an unnecessary layer of abstraction, since it has to be thin, and, in an ideal case, should only delegate test execution to the actual underlying test code.

It is simply worth keeping in mind that you can always opt to implement your tests as regular JUnit or TestNG ones.

A couple of options to choose from

I have described a couple of options that you can utilise in your test suites and during your test automation. They have different learning curves and require different sets of knowledge to apply, so I’m not advocating for any specific solution above. I’m simply hoping I could show you some interesting ways and alternatives to spark your imagination about how you could simplify your or your team’s life when you are using BDD based test automation.

If you think I missed any other ways of simplification, please let me know on The Club (link required).

Resources

For more information

Beating The Odds In A Competitive Job Market: Top Tips For New Software Testers

Rosie Sherry — Sun, 18 Aug 2024 09:46:11 +0000

Land that elusive first software testing job with these simple tips!

by Mirza Sisic

Job hunting is never easy, but it's especially challenging when you're a junior software tester. You're competing with an annual wave of new college graduates who are applying for the same junior roles you are. And then there are the people from other disciplines who are looking to get into IT by starting out with a junior role.

To improve your chances, try to stand out among the competition. First of all, make sure your CV is concise and readable. If you're coming to software testing from another field, emphasize your soft skills as well as the skills from your previous profession that are transferable.

Build A Network, Build Relationships

Join local software testing communities, like meetups. You'll be able to expand your network and make new friends by getting to know like-minded people. Some of these people are likely to work for local companies, and once you get to know them and they see you are eager to learn, they might just recommend you for hire at their place of work. Having someone vouch for you puts you ahead of the game when you apply for a job.

Building quality, long-term relationships with people is arguably the best thing you can do for your career. Being active in the testing community says a lot about you: people who are involved in groups related to what they do for a living tend to be passionate about their craft.

Having a solid network is great for job recommendations, but that's not all. It's great for support, too. The learning journey can be lonely, but in a community, sometimes you can find people who can be buddies along the way. We are heavily influenced by the company we keep, so if you socialize with smart, friendly people who are learning and trying to get into software testing, their good qualities and enthusiasm will have a positive effect on you.

Work The Social Media Angle

Use social media to your advantage as much as possible. Make sure your LinkedIn profile is polished, connect with people (especially recruiters), follow industry leaders, comment on others' posts, engage in meaningful discussions, and show support to others by sharing content and leaving online reviews. LinkedIn's recommendation feature is a great way to vouch for someone's skills, and they often will be happy to do the same for you.

You can use any other social media platform as well. You want your entire social media profile to support your claim of being an engaged, talented software tester. If you want to post or share "just for fun," that's OK sometimes, but consider opening a personal account for topics not related to software.

Try to participate in hackathons and similar events, or get involved in open source software. Activities such as these will increase your chances of getting noticed by people and prove your dedication.

Write And Share About Your Learning Journey

Consider creating a blog to recount your learning journey. You don’t need to be an expert at something to write about it, and it can give you some positive exposure. I once got a full-time job mainly because of my blog, and the blog resulted in a few freelance content writing gigs too. A blog is yet another way to show your passion and interest in the craft of software testing.

To get started, you can treat it as a public journal or diary. As you learn new skills, consider writing tutorial blog posts, as the act of writing them will enhance your learning. We learn a lot by teaching others.

Take A Chance On "Cold Email"

Don’t limit yourself to applying for jobs that specifically require juniors — apply to other jobs too. If a company likes you they might find a spot for you or contact you later on if you leave a good impression. Also, it can happen that the company is looking for a mid-level tester and the candidates they've seen so far do not impress them. They might just give a chance to a promising junior like you.

Not all open jobs are advertised. Research companies that you might like to work for, and send them your CV with a nice cover letter that mentions why they appeal to you: their values, their tech stack, their product, and so on. Ask specifically if they have any openings at the moment. Internal recruiters for many companies are available for messaging on LinkedIn.

Sending cold emails can get you an interview or land you a role in the future. Being proactive is a highly sought-after trait that any organization worth working for will recognize.

Use Job Sites Specialized For Software Testers

Some websites offer jobs primarily for software testers. One such job board is available on the Ministry of Testing website. The jobs on the MoT site are curated and hand-picke, so you can rest assured that these are jobs in prominent companies, offering great working conditions for software testers.

On many job websites, you can filter for testing jobs and save those filters for later use. Remote.com and TestDevJobs offer this feature.

To Wrap Up

Be consistent in your efforts and understand that getting that first job is the hardest. It can take anywhere from a few months to a few years.

If you get rejected, ask for concrete feedback so you know what knowledge gaps need to be addressed next. While it can be discouraging at times and hard to find the motivation, surrounding yourself with people who have similar goals can help you get more motivated and get you into a state of mind when you are constantly learning and applying for a new job. As you iterate, you'll get better at it, and eventually, that first job will come along.

For More Information

Getting Hired - Ministry of Testing Collection
A Community's Guide to Your Software Testing Career - Ministry of Testing Collection
Read the Latest Software Testing News - Ministry of Testing News Blog feed
Meet Fellow Software Testers IRL - Ministry of Testing Meetups

Originally published at Ministry of Testing.

Rosieland Roundup 161 - Choose your own Slack Adventure 🤠

Rosie Sherry — Tue, 17 Jan 2023 02:12:26 +0000

⛄ Do you want to build a snowman or a community? I might be building both this week!

🌈 On Rosieland

🤠 I just joined a Slack where you could “choose your own adventure”

📝 This week in community

✨ Shout out to a new community writer who is also speaking to my rosie heart.

⭐ #01 Make Community the 💜 of your Product Strategy - Becky Pierson

Is DMing harming your community? - Katerina Bohle Carbonell
In 1999, the Word “Community” Took on a New Meaning on the Web - HackerNoon
Products with community at their core - Sarah Drinkwater
Building a people product - Lattice's growing community of HR professionals - Threado
Spotify Community Dissection - Bri Leever
The Idea of the Beloved Community - Susan M Pollak, Pyschology Today

🛎 Rosieland Marketplace

Highlights of events, sponsors, our community consultants and jobs list.

🗓 Attend community events

🌈 The UX of Community - How can you create a great community experience? Use UX and Product approaches to make communities people love. (Get 20% off)

🙏🏽 Sponsors:

🚀 Discourse - The powerful, open platform for communities of all kinds. From companies to creators, thousands trust Discourse as the place to build flourishing, civilized communities.

👋 Threado - the command center for community builders. Get insights, automate workflows, and activate more members across Slack, Discord, and other platforms.

🤝 Hire community consultants

🇺🇸 Jake McKee - is a long time community consultant and one of the founders of the modern community movement, having who has worked at companies such as Apple and LEGO. His mantra for community development is “Everybody goes home happy”, ensuring that both company and community get what they want in an open, honest collaboration. Jake created Dinner5, an invitation-only monthly dinner series that brings senior online community leaders together for conversation, connection, and camaraderie.

🇺🇸 Max Pete - Offering services in community coaching, community platform and launch planning, and community audits. My ideal client is either looking to launch a community or has just launched one and looking for support.

Who is working on building communities?

Rosie Sherry — Tue, 10 Jan 2023 20:31:23 +0000

I'd love to meet other community people here.

Say hi! 👋

Community engagement is so 2022. Here are 10 things you should obsess over instead.

Rosie Sherry — Tue, 10 Jan 2023 20:29:43 +0000

☀️ Hey everyone! It’s time to encourage some better community habits!

I recently asked what was “so 2022 in community building” and one answer that poked its head through was engagement.

It’s not that community engagement within itself is bad, but the recent obsession with vanity metrics over progress is frankly quite depressing.

To avoid me re-hashing what has been said before, here are some posts specifically on engagement should you want to explore:

If not engagement, what can we obsess over instead?

Thanks to Francisco, Max, Cagri, Sonali, Haley, and Briana for helping seed the ideas for this post.

Here are some ideas on what you can choose to obsess over instead.

1. Obsess over alignment

Community building is full of distractions. So many distractions.

It’s he said, she said, they said.

It’s seeing that spark of an idea.

It’s seeing all the possibilities, through the connections, the relationships, the conversations being had.

Not all distraction is bad. However, problems start to occur when the focus is lost and misalignment happens with the rest of the business.

🎯 Obsess over alignment to get continued backing from the business.

2. Obsess over community discovery

You can never know your people enough. Understanding all the little things about your people matters more than you think.

What they write about. The things that bring them joy. Their pains. Their uniqueness. Their goals. Their ambitions. The journey they aspire to. What they obsessively care for.

🔮 Obsess over community discovery to make them feel like you understand, care and can read their mind.

3. Obsess over experimentation

Nothing stands still. There’s a very high probability that the needs of your community will change. People and the world change quickly. Their wants and needs. Move with them.

Community culture needs experimentation at its heart. The willingness to ask hard questions. To constantly try different things out. To make adaptions.

If you don’t experiment, you can’t change effectively. Work towards creating your own processes, frameworks and ideas towards what makes a great hypothesis and experiment.

🚀 Obsess over experimentation to seek progressive growth.

4. Obsess over community experience

It’s hard to get people to join communities, be sure to celebrate your upwards graph of new members joining. However, take it further than that, the community experience is more than just joining and onboarding.

Map out a member’s journey with or for them.

Discover their joys. Their pains. Their goals and ambitions.

Understand the problems they want to solve. Give them what they never new they never knew they needed.

🗺️ Obsess over community experience to create exciting new pathways to explore.

5. Obsess over balanced growth

Growth is great. Every community wants to grow.

The key is balanced growth — for the community, the members and the ecosystem. Communities do not live in isolation. We feed off many things.

Growth is not vanity graphs. Growth happens in community flywheels. Growth is qualitative and often unmeasurable. Growth is about understanding the living system you live with in.

🔄 Obsess over growth to become a regenerative community.

6. Obsess over retention

New members are shiny and exciting. We need to find that same excitement with retention.

Retention is repeat attendance. It means new ideas. It leads to collaboration.

Retention is depth. It is familiarity. It is making memories. It is what creates real and lasting change.

✨ Obsess over retention to achieve radical and meaningful change.

7. Obsess over connections, relationships & trust

We can achieve a remarkable difference with a just a small dedicate few.

Find your people and care for them. Follow through with your words with action.

Be there when they are down. Seek help when you need it.

Think of them when you experience life. Be there in the highs and lows.

🤝 Obsess over connections, relationships & trust to help find your people.

8. Turning your people into successes

Community is about your people and your vision.

Help them succeed and you will too.

Build up their knowledge. Increase their confidence. Give them opportunities. Save them time.

Help them feel seen and get that feeling of belonging. Give them depth when everywhere else gives shallow-ness.

🌎 Obsess over member success to change the world.

9. Obsess over impact

Community requires people. It needs engagement. Conversations matter too. However, most of all, it requires impact.

What is a community without progress?

What is it if we have no outputs to show?.

What if there is lack of clarity on the goals to be achieved?

✅ Obsess over impact to generate outputs that matter.

10. Obsess over leadership

The hard decisions are what turn you into a leader. Do as you say and live with integrity. Chase the hopes and dreams of your people, and balance them with transactional needs.

Have conviction in your dreams to act as guiding decision making principles. Show up. Participate. Be open to new ideas and perspectives. Be willing to listen, learn and change your mind.

💛 Obsess over leadership to follow your heart over the hype.

📌 Obsess over community the quick reference list

Obsess over alignment to get continued backing from the business.
Obsess over community discovery to make them feel like you understand, care and can read their mind.
Obsess over experimentation to seek progressive growth.
Obsess over community experience to create exciting new pathways to explore.
Obsess over growth to become a regenerative community.
Obsess over retention to achieve radical and meaningful change.
Obsess over connections, relationships & trust to help find your people.
Obsess over member success to change the world.
Obsess over impact to generate outputs that matter.
Obsess over leadership to follow your heart over the hype.

What else would you obsess over? Let us know in the comments.

🌈 Visit Rosieland for more things like this.

What is a community tool?

Rosie Sherry — Mon, 19 Dec 2022 11:00:35 +0000

🔥 What makes a community tool is such a spicy and debatable topic, one that continually gets me fired up.

When people think about community tools the natural tendency is to think about chat tools like Slack and Discord. Or forum type tools like Discourse or Invision. Or we can think about more social tools like Facebook Groups or Twitter Communities.

The assumption becomes that, for it to be a community, everyone must have freedom of voice. And that it must be a many-to-many relationships.

The reality is that good communities find a balance. It's not a free for all. It's gathering, understanding and working towards solving problems. It's also managing the overwhelm of conversations and deciding what conversations need to happen and where.

In community we need to do more than just talk. Communities exist to create progress, to create progress we need to do more than just converse. Yet all the above tools focus on conversations only. They are not bad tools. They are great. But they are just part of the picture of what a community is.

This is actually more problematic than we may realise because when people think about the community they need to build, they jump almost immediately to these tools. Even asking what tool they should use before considering any other aspect of what the community should look like.

It's even gotten to the state that we feel we can only have one tool. Like the community has to be a forum or a chat tool. The reality is you can have both and you can even add more onto it if you like. Rosieland has a blog/newsletter, forum, a Slack (for paid members), a Twitter Community, and a LinkedIn Group.

And we are not the only one who rocks up community like this. It's a mindset that building community requires many tools. And the community tools to choose from aren't completely obvious.

Here is my rosie perspective.

🌈 A community tool is one that facilitates communication and the publishing of information.

And yes, sorry, this means so many potential tools: social, blogging, website builders, google docs, Notion, white board tools, email marketing, newsletters, podcasts, videos...and of course chat and forums. They're all community building tools!

Communities are products, we need to think of them in that way. To create a good product you need to do all sorts of things to make that product a success.

In practice and in a community context, this means you need things like:

a website
ability to publish or curate content
an email list
a social media presence
ability to create and host events
a place to have discussions, virtually or in real life, sync or async
focus on progress through the outputs you are working towards
a focus on sustainability and growth

Therefore, to build community you need a whole range of tools to help you get there, just like any product needs to make use of a bunch of tools.

We have 'email marketing' because marketers developed tools around email to do marketing via email. You can almost hear marketers from the past asking themselves how they can do better marketing...and email became the thing. There are many ways to do marketing. Email is just one of them.

Email marketing is not nearly effective as it once was, it's actually pretty overwhelming now. However, that's also a good reminder of how tools and trends change. We must keep an open mind.

There's no reason why we can't use email to build community, but are we marketing to our people? No. Or at least, we shouldn't be. 😈

When we use email in community we use it with a different purpose:

to uplift people
to educate, share news or member content
to invite people to a discussion or to comment
to invite people for a 1:1 chat
to invite people to events
to invite people to speak or write
to ask them questions
and more, there is literally no limit.

Therefore, email marketing and newsletters are a community tool.

We can also look at content in general as building community. I love using Smashing Magazine as an example. They focus intently on their people. They care about great quality content, written by people that care about their craft. They use their website and Twitter a lot to elevate people. Their community is strong without their actual community membership, I believe that came much later.

Smashing Magazine links out and shouts about its members all the time. The below image shows them highlighting a member of the week and links out to blog posts members have written. This is on the homepage of their website and also on Twitter.

How does this not build community? Do you know of a better way to show you care about your people?

Events are great for community building. Some have community features embedded within, chat down the side or the ability to collaborate on docs together. It's hard to keep in touch after events, which is where other tools come in handy, especially email and blog posts, to keep members informed about all the things.

Podcasts are a great community building tool too. You can have deep conversations with your people. You build relationships, understanding and knowledge. You can then keep people informed about your podcast via email and social. Please, someone, tell me how does this not build community?

Substack is an amazing community tool that no one calls a community tool. It's a newsletter tool, apparently. Yet it's pretty amazing at allowing collaborative publishing. People actually comment and like posts. They have threads which is basically a mini version of a forum. Not to mention podcasts. Ability to email easily. And of course you get access and insight into your members.

Substack make it easy to collaborate with guest writers.

Substack also taps into a network effect, not only by supporting and making it easy to read latest posts, but also by switching on recommendation of other newsletters—a community approach to this would be to use this feature recommend up and coming member newsletters.

What I'm getting at is that none of these tools work in isolation. To build community we need a bunch of them. Less to start with, more as we grow.

Of course, just because you are using any of these tools, it does not mean you are building community. You build community when you use the tools with the right intention.

It's where the tools help us get that matters

Sometimes I think we forget about the goals that we are working towards, we get influenced and distracted by vanity metrics. We often feel that these tools help our communities get somewhere, but do they? How can you prove it?

You can have a forum, or even a Substack thread with hundreds of comments. But so what if that doesn't help people progress or connect?

At each point of the journey we should be asking ourselves if the effort we are putting in is worth it.

what is the ROI?
is there a simpler way to reach our goals?
how is this actually helping people?
how do our people feel?
how are our people making progress?
why would our people choose to come back?
how are we showing we care about our people and our cause/industry?
where is the energy happening?
how can we create MVCs first to prove our hypothesis?
how long can we hold off on adopting any new tool?
how will we sustain it?
how does it fit into our community flywheel?
who will do the work to ensure it is a success?
is this the work we want to do as a community?

It's our responsibility to deliver value for money. And part of that is deciding the tools we use and the positive outcomes we think we can achieve.

Of course good and bad tool choices can be made.

I had a community on Discord and ultimately it turned out most of the people there didn't like Discord. Moving to Slack actually did fix things. That community is now slowly using more tools, in this instance a Substack.

However, much of the time we can think the problem is a tool problem when it is not. The amount of times I see people moving from a Slack to a forum and even back again to a Slack is hilarious.

Trends can change too. A Slack or a Discord use to be a novel idea and easy to get people to sign up to. These days people are overwhelmed with being signed up to too many chat spaces, or the ones they are signed up to are too noisy. Having a variety of tools de-risks your community, it makes real community business sense to spread the amount of ways you can connect with your people.

Community builders need to get comfortable with quietness and slowness at the beginning of a journey. Yet, I still feel like it is a natural reaction for community builders to panic if their community space has very little activity.

The reality is that we should build confidence through community discovery, starting small and build up those process driven community flywheels. If we have that confidence and that foundational discovery in place, then we can march ahead knowing that our chances of success are higher.

It really does take time to hit on what works, gain traction. And time is often what we and businesses don't give our communities.

Time to:

get to know people
adjust the space
understand what people need and care about
know what we can actually act upon
to create good outcomes and opportunities for our people
build trust
build an email list
become searchable
get personal recommendations
give people confidence to participate

With time we can create a refined and more tactical approach to building a community strategy. It's hard, if not impossible, knowing how things will specifically work out in advance.

Tools can be used for anything, you can just as easily alienate your members than bring them together. Whatever tools you do use, they must all be used with the mindset of building community. The moment you become transactional, people feel it and they run away.

Everywhere I turn I see companies building amazing communities. What makes them great is the focus on helping their members. The tool choice can help.

Letting go of semantics to open our minds to the possibilities

I know some people will disagree and find the need to stick to a certain way of describing tools. And perhaps it is dangerous to call almost any communication or publishing tool out there a community tool.

However, I will tell you this.

Once I started thinking more like this the more it opened my mind to the possibilities that we could create within community. We become less restricted in what we can do. Our creativity can be set free, our ability to see and grow multiplies.

The more we experiment. The more we mix and match all these tools. Then the more we will create new boundaries of what communities can be. The possibilities to create community flywheels almost becomes endless.

And that idea of communities being able to be more, or be better than what they are today is what I'm here for. 🌈

Community growth specialists are the future of community

Rosie Sherry — Wed, 02 Feb 2022 17:30:54 +0000

We’re facing an exciting time in the community industry. New challenges arise as interest grows in the work we do. We have the opportunity to forge new community paths.

In the instance of expertise and community career paths, we are moving away from very basic job titles of ‘Community Manager’ and ‘Head of Community’ and towards more specialist roles. Increasingly companies are realising that our work actually involves much more than just ‘chatting all day long'.

The future of community needs us to re-evaluate the roles and career paths that exist

Now as a community industry we have no choice but to create specialists roles. We don’t just ‘manage’ communities. We build them. To create anything — a house, a website, an app, a book, you need various skill sets. It becomes unreasonable to expect one single person to do it all.

Sure, you can build a community alone, but as it grows it becomes impractical, inefficient and often leads to burnout.

I’ve written previously about a whole list of potential community roles, some aren’t entirely serious, but I still list them as a way to help us open our minds up the type of work that we could be doing.

One such specialist role I’d love to explore more is a ‘Community Growth Specialist’ — infact, I would argue that this role will become crucial to all (serious) communities.

It will become a role that could make or break a community.

The community growth lines are blurred

We need to be careful to not jump too quickly to assume what a community growth role entails. It’s pretty easy to get lured in with vanity metrics, or ahem, marketing. To show upwards trending graphs that really don’t give a complete picture of the health of the community.

We have to be clear in our minds that scale does not equal growth. Often when things get big we sacrifice or neglect what we cannot quantify with immediate value. We celebrate the new members coming in, yet will often fail to nurture them.

Therefore I do not believe this role is a simple case of replacing the traditional ‘growth hacker’ mindset. Growth in community is not marketing. Nor is it a growth hacker type role — it’s not about going in with a bunch of tactics to increase engagement.

The reality is some of the things we do as community growth builders look like growth and marketing. For example, sending out emails could be perceived as marketing. However, email is really a communication tool. Marketeers communicate. So do community builders. The goals each profession are trying to achieve are different, the tools are sometimes the same.

Another example is using social media for community. We can very much use social to build community, this does not mean it is social media marketing. Again, this comes back to conversations and communication.

Marketing have owned any tool that communicates with people. We must learn to look at many of them as conversation tools, not marketing tools.

It feels like tools define careers, however, I see this as a ‘we just happen to use the same tools’ scenario — our tools do not define our roles. We can use tools creatively and differently, especially when they involve communication.

The lines are blurred. There is no denying that. As we advance in our community industry I hope we can create more clarity.

Growth comes with data, value and density of relationships

Growth in a community perspective is not necessarily about the metrics or numbers. Growth is not scale. It’s not about getting more members in the door, or getting more forum conversations happening. When we grow a community it is about the value and relationships we create.

We create value by doing things like:

having conversations
connecting with the right people
research, listening and understanding our people
being helpful
saving time
uncovering information
creating products of value

So, what do community growth people do?

Community growth people understand the mission. They have their minds set on big dreams. They want to help change the lives of the people in their community. They have their feet grounded in reality, yet are focused on where the community needs to go to succeed.

They also understand the boundaries, such as:

community is not marketing
community growth comes from a strong foundation
relationships are key
things like ads will likely not work
community grows at the speed of trust
listening and researching (aka Community Discovery) is crucial to understanding how to grow
instead of growth hacks, they seek opportunities

A community growth role is more about having the ability to understand the community strategy as a whole and identify ways to grow a community. Part of it can be improving conversion rates. Or ensure community processes are tight-knit and growth-oriented. It could also be about addressing the content and the culture of the community.

However, more meaningful parts could be using community research to learn to deliver extra value. With great research come great opportunities. Community growth people learn to spot gaps to fill. They understand the industry inside out. They know what people need. And they jump on opportunities that help members or the community grow.

Community growth builders know that growth in numbers is not all that matters. They know that context matters and vanity metrics can equally harm a community. As much as they might look for opportunities to grow, they may also look for ways to cut back on community debt, or the overwhelm of noise. Just like in the SEO world it is recommended to remove unnecessary pages to help websites gain traffic, the same principle can apply to community — less is often more.

Community growth is not about more. It’s about doing better and creating value. It’s about retaining over churn. About understanding where people are at in their community journey and (co)creating something to help pull people in and bring them together.

Community growth specialists get good at creating community journeys that work. They understand growth tends to come slowly. They understand the pieces that work within a community flywheel. They know that if one piece of community flywheels are removed then it could all come tumbling down.

Importantly, they know when is the right time to act.

Good growth people:

know when a good idea from a member is worth backing are strategic rather than in the day to day trenches of the community
know what makes the community tick
create a bridge between stakeholders and the members
experiment with ideas and conversations
know that they need to invest in their members
capture feedback and progress to show what is working
love creating and improving upon community flywheels
understand that many communities are distributed in their nature and develop strategies to pull them in
can report on quantitative and qualitative community data
invest in community opportunities
optimise for many parts of the community journey
support reducing community debt

Ultimately, community growth specialists understand what makes communities tick and have a strategic view of the future of community. The moment we stop focusing on growth is perhaps the moment our communities start to become irrelevant.

A community vision is better than a community idea

Rosie Sherry — Thu, 01 Apr 2021 02:54:18 +0000

The whole thing of ‘validating an idea’ is thrown around so much in the startup and indie world. I nodded my head along for quite a while in agreement, that perhaps I should apply similar concepts to my community building efforts.

However, when I thought about it, I realise that I’ve actually built communities without validating ideas, instead I do it more by validating a vision.

I find so many people get stuck on validating ideas, especially when it comes to communities. They become so focused on the short term thinking of whether ‘the idea’ is working, rather than thinking longer term of whether they are taking steps in the direction of where they believe they want to head.

This is even more important for communities. The things we build with our community have to align with them as much as us, as founders of people who work for the community.

One cannot simply test and idea on a community and expect it to work. You need to do the ground work of building relationships and trust. An idea without strong relationships and trust will likely have minimal impact when compared to one with great bonds.

In addition to this, communities are most likely built on many ideas, or many experiments. It is the overall vision that keeps things going.

Jason Fried on not being able to validate an idea

People want to be certain about things, but really we can’t be certain about anything. You can do as much validation activities as you like, but at the end of the day you have to go and build the thing to see if you can make it happen.

And classically, Jason says it really well. The market will tell you what to build and if you need other people to tell you what to build then you are lost. You need to validate something by believing in it.

Having a vision is key. And no one but you will work towards that and developing the deep knowledge that is required.

📺 Watch the video, it’s really short!

Even if you do validate an idea…

The world is forever changing, companies come and go all too quickly. Focusing on idea feels to narrow minded and closes your mind to opportunities. However, focusing on a vision keeps you open minded to the possibilities you could create.

Should a big world event happen, like, ahem, COVID, having a vision will hopefully pull you through. On the flip side, having a functioning business idea may not be enough.

Become a believer

When it comes to building community, you need to be a believer in what you are creating. It doesn’t mean you need to have the answers. It’s more that you believe there is a need for what you want to build.

People will ignore or laugh at you all along the way. They will tell you that the ideas that you generate won’t work. Of course they’ll say that. They don’t know what you know. You can’t expect them to.

The belief is what will keep you going through the hard times. The belief brings the understanding that this is a journey. It is what will keep you constantly learning. It will make you understand that a landing page will not really move the needle. That the number of email subscribers doesn’t matter too much. That you need to keep chipping away to build something meaningful.

To be a believer, means obsessing over something that no one else will. Your obsession becomes your competitive advantage.

Idea vs Vision

I'm still kind of processing these thoughts in my head, but here are some key differences between ideas and vision, take it with a pinch of salt:

Validating an idea is fixated on a specific problem to solve
Validating a vision is focused on deciding whether the bigger picture is something you believe you can contribute to.
Validating an idea ignores many aspects of the bigger picture, it looks for biases to prove that it will work
Validating a vision means caring and understanding about how everything works together.
Validating an idea is short term thinking
Validating a vision is long term thinking
Validating an idea means seeking approval from other people
Validating a vision means you are confident about the decisions you make
Validating an idea means decisions are focused around your specific product.
Validating a vision means every little thing you do aligns and contributes towards your overall (community) goal.
Validating an idea means little change in your products
Validating a vision means your product ideas could change over time

My reflection on Ministry of Testing

When I did Ministry of Testing, my vision was to change the software testing industry. Crazy thinking at the time! I didn’t actually think I would make much of an impact, but that idea was always there in the back of my mind. And that frustration of there just not being enough things out there for testers kept me pushing forwards.

Each week, each month, each year I learned more. I created multiple paths, and crossroads. I kept exploring. Listening and conversing. And always trying new things. Forging new paths and opportunities, to find what worked.

I did stupid and unprofitable things along the way. I tried and discontinued a few ideas. For example, we did a printed newspaper for a couple of years. It was so much fun, but not really a something we could sustain financially.

As time went on, I was that person, or that business, who was making an impact. Not because I had a great product, but because I kept pushing towards my vision.

All the way through I would be asking myself ‘ are we creating positive change for the software testing world? ’. That was the question. The vision.

Events had been our bread and butter in terms of money. Before we did events I spoke to people about doing them, and they all rejected my ideas. They wouldn’t attend, they wouldn’t pay, is what they told me.

I did it anyways! 🤩 Because of it aligned with my vision. And because of all the things I knew that they didn’t. I believed!

My vision with my (Rosieland) community building efforts

I can apply a similar vision idea to my current Rosieland efforts.

Yes I have this vision of changing and transforming the community building world. Putting that into words feels crazy to say, but it is what keeps me going.

I intentionally took small steps to create habits all along the way. I never set out to do a paid newsletter. Nor a course. Nor a community. I had no specific product ideas, or I had plenty of them, but I didn’t want to focus on launching any of them.

Instead I focused in on confirming with myself whether this was a path I wanted to take. A path that I could stick with longer term.

Rather than declaring a big idea at the beginning, I started with a simple curated newsletter to help me study and make a decision for myself that this was an area that I wanted to develop a vision in. Along the way I’ve learned so much and connected with so many people.

The fact that I’m enjoying it is what is keeping me going. In this instance, this was a huge part of validating my vision.

My previous community was a 10+ year journey. I wanted to be 100% confident that being in the community world for at least that amount of time was the right thing to do.

To validate my community vision I will always be asking myself stuff like:

Is this something that I really want to do for the next ten years?
What should I be exploring?
Am I thinking about the right things?
What should I do that others are not doing?
Also, what are the things that people are doing that I don’t like, or disagree with.
Does it bring joy and excitement?
Do I have the energy?
Do I feel there is room for Rosie to grow something?
Does the community world need me to do something?
Am I cut out for this?
Why should people care?
What is it I really need and care about?
Am I able to pull people into my rosie ways?
Am I happy doing a little bit every day to work towards that vision?

Asking myself these questions on a regular basis keeps me real

If there is something bringing me stress or unhappiness, I need to question that and make a decision whether I’m on the right path and maybe consider that my vision needs changing…or ditching.

I know myself better now. And for me I have to be 100% into something to thrive, otherwise I fall into a deep dark hole.

Admittedly with Ministry of Testing, I wasn’t 100% into it, I ignored my instincts for a while, but a few years in I knew that whilst I had a vision, it wasn’t quite aligned for me.

As a founder of that business, as much as I loved the people, it was a really slow and tough process to remove myself from it. I couldn't just quit, well maybe I could've, but it felt wrong. Instead I got stuck trying to find a way out.

I think about this often to ensure I don’t make that mistake again. Which is why with Rosieland I wanted to to tread slowly, cautiously and with the view of building up my own confidence that I was heading in the right direction of building better communities.

This week in community building - Issue 46

Rosie Sherry — Mon, 03 Aug 2020 18:47:28 +0000

Welcome to another week of community building news!

This week in my paid newsletter I wrote:

How to start a community

A Circle of Gifts

An oldie but a goodie. By Charles Eisensten.

Community is woven from gifts. Unlike today's market system, whose built-in scarcity compels competition in which more for me is less for you, in a gift economy the opposite holds. Because people in gift culture pass on their surplus rather than accumulating it, your good fortune is my good fortune: more for you is more for me. Wealth circulates, gravitating toward the greatest need. In a gift community, people know that their gifts will eventually come back to them, albeit often in a new form. Such a community might be called a "circle of the gift."

What’s the deal with Audience Engagement?

Erin Mikail

The role of an Audience Engagement Editor is just that - to engage with your audience, build relationships, sort of a community. The term can be a sort of catch-all and is much like the word “community” used in tech. No one seems to really know what this means exactly, and it often just lumps into all of these things.

Issue #22: Belonging and Mutualism

From the Future of Belonging

We are all in this community, society, country, and planet together. For any one of us to be free, we needs to endeavor continuously to work for us all to be free. Our separateness is a bit of an illusion as this pandemic continues to show us how mutualism can carve a path to freedom through rather than in spite of our connectedness. Designing for belonging is a way to reinforce this connectedness and move toward resilience.

One Word Spared Norway From COVID-19 Disaster

Dugnad (pronounced doog-nahd); a Norwegian cultural tradition where community members work together towards a common goal, for the greater good for all.

Chartered Waters

From SuperFeed

So we thought, why not chart our assumptions of how communities behave? We stress, these are assumptions based on personal observation and experience. If you ask “where’s the data?”, we will look you in the eye, point to our bellies, and proclaim “Our gut.” But while we acknowledge the unscientific nature of the arguments, we hope to provoke serious thinking.

Why do you think this community has died?

From Designer News.

Always interesting to see people discuss why a community has died within said community. 🤷🏽‍♀️

More community building news...

❤️ The Six Conversations. Building Community Among Citizens - Peter Block ❤️
The risks of building your paid community on rented land - Niklas Lohmann
How Do You Design a Community? Start with the Why or the Who - Design Museum 🎧
The Impact of Toxic Influencers on Communities - Intense Minimalism
Healing Societal Division Through Community and Technology with Lisa Conn - Create Community 🎧
2 years, 800 members: BoiseDev builds community news, for its community - BoiseDev
Community Cultivation – A Field Guide - Educopia
Talking platform responsibility and community safety with Melanie - Community Finder 🎧
CMX Summit speaker applications are open - CMX
Three Metrics Every Community Manager Should Track - Noele Flowers
Why You Need A Community Manager (and what happens if you don’t replace one) - Richard Millington
Diversity & Inclusion with Emma Irwin - CHAOSS 🎧
YANSS 184 – How to improve your relationships by systematically de-biasing your brain - You Are Not So Smart 🎧
What makes a Facebook groups “off the charts” active 👩🏻‍💻 Lindsay Russell, Facebook - GetTogether 🎧
The Internet of Beefs - Ribbon Farm 🐄

🥰 Appreciate this newsletter? You know sharing is caring! 🥰

Share Rosieland

Building Communities with Questions, Not Answers

Rosie Sherry — Fri, 08 Nov 2019 12:12:21 +0000

We live in a world where we expect and demand answers. People come searching for answers and blueprints, but leave disappointed when they don't find exactly what they are looking for. Sometimes they think they've found the perfect answer, only to find out later that it doesn't really solve their problems.

Answers close down discussions. Questions open them up, the possibilities become endless.

Questions is something I've been thinking about a lot recently. I've been practicing asking questions since day one of community building. And it is only now that I realise that asking questions is key to building community.

We ask questions not necessarily to get to an answer, but to open up a new future of new ideas and possibilities.

On a practical day to day basis these days they mostly come in the form of forum discussions and social media posts. Less often it is face to face (irl or virtually).

As a community leader you'll find me asking questions more than giving out advice. I have experience, but I don't have the answers. When you see me or the Indie Hackers social accounts asking questions it's because we want to help you think about the questions you should be asking yourself so that you can discover new things and come to your own conclusions.

Having this focus on 'questions' has given me a new sense of focus. Now whenever I read anything from the IH community, or anything business related I write down ideas for questions.

Originally posted over at Indie Hackers - https://www.indiehackers.com/post/building-communities-with-questions-not-answers-dd36de1735

How do you build momentum?

Rosie Sherry — Fri, 11 Oct 2019 14:00:43 +0000

Some people refer to the slight edge - the little decisions that we make is all that matters as every action that is made is compounded over time.

Others often are familiar with the snowball effect - start small and build upon what you have.

More recently, on an Indie Hackers podcast (about 30 minutes in), I heard the term exit velocity - which is how much professional and entrepreneurial momentum you have when starting you new project or business. Typically when you are new to the world of business it is hard to gain any kind of traction as you most likely haven't had the chance to build up your contacts, relationships, knowledge, experience, capital, investment and so forth.

The slight edge, snowball effect and exit velocity are all important mental models to bear in mind when building your business. The more I see and learn how others are building successful business, the more I see these models have been crucial to their success.

Indie hackers newer to the game can quite easily miss this. They will look in from the outside, believe that they understand why said person has succeeded, but really the underlying factors are down to a million little things that have most likely happened over at least a 1000 days.

The 1000 Day Rule

Rosie Sherry — Wed, 09 Oct 2019 18:56:13 +0000

I became aware of the 1000 Day Rule on the Indie Hacker Podcast with Tommy Griffith. In the podcast he basically says that often it takes 1000 days to replace your income.

So I looked it up. On TropicalMBA it says -

The 1000 Day Rule: Our basic hypothesis: you’ll be doing worse than you were at your job for 1000 days after you start your muse business.

There's a bullet point list in the article above of the different stages of the 1000 days, which I thought was interesting. Yes the post is a bit old. Yes it often refers to the marketing/ebook/affiliate type stuff, but the bullet point journey list is not far off what I experienced.

I then remembered that I posted the revenue from Ministry of Testing, and it was in year 3 of proper business building that it actually replaced by proper income. Interesting :)

Obviously, this won't necessarily apply to everyone, but as a general guidance for indie hackers I think it is useful to be aware of. I often see frustrated indie hackers who are new on their journey. where they aren't see results straightaway and give up hope a bit too easily.