Your Customer's Goal

Your product is successful when your customers are successful.

I have spent months discussing "activation" with investors, founders - and their customers. The first two struggle to figure out the right metric for measuring or defining activation metrics. But their customers have a more straightforward definition: today, am I further on my journey to my goal than yesterday?

"Concentrate on the customer" seems obvious, but how do we do it? More importantly, how can we make our operations into a system that focuses on the progress of our customers?

A few decades ago, Eliyahu Goldratt wrote The Goal, in which he discusses a similar quarrel between operators looking at process metrics and customer-facing innovators focused on outcomes. This book, authored in the 1980s, does not speak directly about software or customer adoption of technology products. But it can teach us much about both.

In a previous generation of manufacturing management organizations, one would be responsible for one part of a shop floor. Supervisors manage success on uptime, output, and measure of "utilization" - for how much of the day is the equipment in motion? 

But this only worked in a well-designed factory that was facing stable, usually growing demand. But things change. Machines wear out better technology replaces them. Fitting new devices on the floor makes the layout more complicated. Markets change too; the specifications for the As the floor mutated with time and the market conditions changed, compounding alterations created inefficiencies rapidly. Old assumptions about "good" metrics became void. 

Goldratt points out that turning on a machine - activation - is a standard metric for productivity. You have lots of uptime on your machines! Hooray! But this is not necessarily related to its contribution to company profit. After all, if the machine's output has to sit in front of a bottleneck process, running it more or better didn't save anything. 

If anything, activation drove up expenses in labor, energy, and likely maintenance debt. At best, running the machine generates intermediate parts that go into inventory. Adding to inventory can look like a win to an accountant since inventory is technically an asset. In reality, excess inventory of unfinished goods and parts drives up costs: warehousing, transport, and upkeep, so they don't rot. Also, even though they might get booked as an asset, they are hard to turn into revenue. Intermediate parts are usually only usable in the company's manufacturing process - selling them outside the company does not usually work.  

Utilization, on the other hand, is when operating an asset contributes value to the organization. Counterintuitively, making a machine contribute better to the system might involve running it less. That way, it creates the intermediate parts in the quantity usable by the bottlenecks, but not more - no more business-destroying inventory. Then the machine can stay quiet, and we start to ask important questions. Do we assign teams to secondary jobs when the big hunk of steel is not running? What does this mean for our overall staffing needs - and costs?

Making money by creating valuable products for the customer is "the goal." The goal is about the whole organization rather than individual or squad performance. No tool or team is an island. Different parts of the system might contribute more or less based on how and when they operate. The links and signaling between them become crucial. 

In a noisy, dangerous factory, simple signals work best. In the Toyota Production System that Goldratt praises in his book, "kanban" cards get passed up and down the line to indicate the relative capacity of downstream machines. Based on cards in hand, upstream crews know how much to turn their efforts up or down to maintain flow. When I have more cards, I can ship more to the next step. 

This discussion of 1980s manufacturing can feel very far away from modern software. But there are lessons here. Let us apply the utilization/activation insight to user onboarding. Instead of viewing the factory as a parallel to internal operations, let's think of it as the customer's journey to generate their desired outcome. In this framework, we sell or operate one of the machines in the customer's factory. 

"Activation" is often about the use of our machine. For example, the measured behavior might be the user creating their first project or finishing a profile. But relative to the customer journey, these are arbitrary, like measuring the uptime of a given tool on the factory floor. Not irrelevant, but often not crucial. Where is the real bottleneck holding back the customer?

The answer can be scary because sometimes the answer is "not here." The product we are offering is not the key to their success. In this case, we should be unsurprised that they do not "activate" in the manner we might hope. 

If this is the case, we have options. One might apply the service to a different customer whose solution is in that critical path - put the machine in another factory. One might decide to use our knowledge at a higher level and manage other tools in the factory - move up the stack. Or we could change our offering to serve a more critical-path need: a product pivot. 

We should see our jobs as connecting our customers with value. Once we are sure we are crucial to their journey, we can ask how our onboarding brings them toward their "job to be done." 

If one is an app-building system, getting them to build their first app is not genuine "activation:" shipping is. Have our customers made the app available to their target customers? If not, why not? We need to understand how our service contributes to that goal. If they do not reach the goal, they will churn out, regardless of how well our internal metrics say our product "worked." 

There is a gray zone where we see an active user who wants to succeed but has not yet achieved their goal. And this is where things get interesting - we might not want them "active." Mere use or hacking around might not be on the path to utilization. In which case, just like on the manufacturing floor, we want to facilitate their "away time" instead of engagement. What do we do to ease their standby window? The win is that they are still in the factory heading toward the end of the line - whether or not they are engaging with our particular machine. 

This all matters even more because of how equity value works for a software-as-a-service business. The value is in the lifetime of the subscription: how long does the customer keep it? You don't care as much about the first month of use - you want the years of staying onboard. This long-term relationship requires that they achieve their goals. In general, there is more value in being part of a success story than being at the center of an unsuccessful one. Success comes from their goals. 

For the app builder in the previous example, getting the client to shipping means that the deployed application has some dependency on your platform. Continuing from that point creates recurring value to the customer without demanding more of their time. The easy path is to keep that bill flowing. And longer lifetime means the present value of that customer relationship goes up. 

The objection I sometimes hear is that one's product is "for lots of people," and so the company remains neutral about how it gets used. As a matter of permission, that's fine. But permission is not the problem - enablement is. They have a goal they have not reached on day 1 of their trial. Provide excellent service, connect with the other parts of their process, and take ownership of the customer's success. 

When the customer reaches their "goal," you will achieve yours.  

Share

I am grateful to the community at foster.co for editorial feedback on a draft of this essay. All errors are, as always, my own.

Photo by carlos aranda on Unsplash

Thanks for reading Sustained Writing! Subscribe for free to receive new posts and support my work.

The Evolving No-Code Mental Model

How should we think about no-code? This technology class is a challenge because it is both disruptively new and an evolution of what has come before. Shifts in our thinking that go with it can be startlingly sudden - and sometimes insidiously gradual. We might not realize our thinking has changed until prompted.

I received such a prompt when interviewing a PHP developer with deep, valuable experience building what many call "monolith" applications. He was trying to broaden his horizons and understand more recent technological developments. This intelligent, thoughtful person asked, what is the deal was with microservices? (For those who have not heard of microservice architecture, I will discuss what that is a few more paragraphs down.) Why don't I just put the code together myself? The monolith worked perfectly well for him for years, and clients paid well for the work. What is the upside?

I see this general philosophy in many professional developers who are "considering" no-code tools but return to those they know and love. These are, by and large, all brilliant people, but they do not see the value that seems so clear to me. Where is the gap? Is it some bias - sticking to one's knitting? A sort of reverse-Luddism? Is there something else going on here?

The issue is the mental model we bring to code vs. that required for no-code. Mental models are the way we think about how a part of the world works. The story that we tell ourselves informs how we predict the behavior of a system and integrate it into our lives. In technology, broadly adopted mental models evolve with the state of the art, tooling, and training. 

A technology with lots of opportunities (e.g., a fantastic state of the art) but that is arcane (bad tooling) and nobody knows how to use (lack of training) is not generating much economic value. One that is hard to work with but has a phalanx of trained people can drive value bounded by the trained population. But when the technology becomes well-tooled, the scale of application shifts from wrangling the technology to associating it with one's job.

We can see this evolution in the history of information technology itself. 

In the beginning, there was code, and it was tough to understand. Even leaving aside the olden days of punch cards, Low-level abstractions like Assembly, Pascal (remember that?), and C introduced in the 1970s allowed a programmer to impart instructions to machines. These languages looked arcane to most people, but they were attempts at building a bridge between how the computer thought and how a human could express that thinking. Most of us cannot dream in binary. 

As computers got more powerful, the languages and abstractions improved because we could afford to have the computer do more work translating between human-written intent and low-level instructions. The available computation horsepower permitted the use of higher-level languages. Object-oriented programming created a metaphor to facilitate code re-use. "Intermediate-language" runtimes like Java and .NET allowed a wider variety of easier-to-understand programming languages that did away with low-level concerns like managing memory. Eventually, scripting languages evaluated at runtime - like Javascript, Ruby, and PHP - were practical and could even be fast. 

The people who could be successful at the outset were coders - people who could articulate their intents using these languages. As the languages became higher-level, the skills required to work with them generally declined, and a more expansive universe of professional developers - many without college degrees - could be successful. 

The next iteration came in the form of package managers. In the simplest form, one could copy-and-paste the files containing this dependency code. To make this easier, package managers such as NPM (Javascript), Gem (Ruby), Composer (PHP)- and more for other languages - arose to make it easier to include this code without copying and to keep up to date with the dependencies that a given sub-project might have. 

Share

The burgeoning popularity of open-source made package managers much more powerful. Open source is a legal construct in which the owner of one bit of code - say, a dependency - permits another person to use that code in their project - say, an application - without a fee. Standardized, liberal open source licenses like LGPL and MIT made including dependencies much safer and, eventually, the standard way of working. 

The availability of these expertly-built projects shifted the critical skills for developers from writing the whole thing to linking these dependencies with a layer of business logic and an intended user experience. The amount of code in a given application that one would "write" shrank as dependencies handled more low-to-intermediate concerns. 

Many modern developers hold a mental model of software based on this environment. They happily pull a gem or NPM package to extend the functionality of their intended application. In this way, they compose their code, which is tantalizingly close to the mental model for no-code.

However, this model sees the world through the lens of compilation. The output is all under their control. The packages work together in the same memory space - like multiple organs in the same organism. The objective is to build the "six million dollar man" - a single person with extraordinary ability. 

Microservices as a model take us closer to no-code. In microservices, multiple programs working in concert execute the intended jobs. These programs collaborate, but they are separate processes. Each program can be smaller and - in theory - simpler. One tricky part is breaking up the concerns to be handled by more atomic microservices, and another is managing the links between them. As a result, complex system management emerges as a primary skill set. 

But even here, using microservices is like hiring employees to help you do your work. You are no longer doing all the work yourself, and your skillset moves from doing to managing. But they all work for the same firm, so you are responsible for training them all. 

Utilizing third-party software-as-a-service is more like outsourcing to agencies and bureaus. The concern I see outsourced most is authentication - managing the secure access to one's resources. Services like Auth0, Firebase, and AWS Cognito specialize in making sure that the person asking to use your resources is who they say they are. Leveraging their expertise has two effects. First, it improves one's security profile, and second, it decreases the complexity of one's system. The increased benefit with reduced cost - what could be better? The number of hosted services that can similarly outsource concerns is growing by the day. We are moving from managing servers to being "server-less" and from integrating code inside our runtime to being "service-ful."

We can best understand no-code with this "service-ful" model in mind. One orchestrates many outside services to create outsized value. The critical skills are in selection, orchestration, and composition, rather than crafting using a particular tool.  

No-code is a mental model that, to me, seems like a predictable evolution of software development. Emerging technologies (e.g., quantum, AI, distributed databases) will - for a while - require code because they are not as refined. That's what makes them "emerging!" But for a vast array of business-applicable use cases, this model will drive value.

The evolution of the mental model makes me think that the win is not convincing a developer with a decade's experience to start implementing projects based on no-code tooling, but in the many non-developers who want to solve their problems. They would not have been able to "leap" to code-based solutions without a lot of help, but the mental model of "some assembly required" looks much more like that of children's toys. 

While more accessible for a business-side person to understand, the issues are not necessarily evident to the untrained observer. The complexity is in the business needs, rather than the technical understanding required to be successful. And that complexity is where the business expert has the experience and advantage to unleash value. 

Where does this relationship go next? How can we unmoor ourselves from the perceptions that led to this moment, such that we can be free to imagine what is next? What mental model starts where the technology is today and helps us with the subsequent evolutions? And what new business models will arise from those mental models that will unleash value for us all? 

These questions keep me up at night because the answers will be the keys to making this technology work for businesses in the coming years. What worked today will not work tomorrow; that goes for business practices, technology, and our mental models. 

Thanks for reading Sustained Writing! Subscribe for free to receive new posts and support my work.

I am grateful to the community at foster.co for editorial input on drafts of this essay. As always, errors are my own! 

Photo by Alex Motoc on Unsplash

Go Smaller

Do less of everything. And more of it. 

I started writing morning pages about seven months ago. Morning pages are a practice evangelized by Julia Cameron in The Artist's Way in which one writes continuously in pen on a notepad for about three pages. I do this while waiting for my morning coffee to brew. The practice now takes about ten minutes. When I shared this with another practitioner who struggled to keep up the habit, she was astounded. How could I write so fast? I shared my secret: my notepad is half-size. In contrast, she wrote on a legal pad. She was writing over twice as many words per page as I was.

The difference in results between us was that I had a habit I had carried forward for over 100 days (at that time). While perhaps more "correct," my friend's ritual was harder to maintain because it consumed so much of her morning. By going small, I enabled consistency of habit. 

Another recent example is meditation. I started the practice several months ago and wondered what would drive value. The key to getting started was keeping each session brief. A mere five-minute meditation could teach me techniques and give me a rest from the screen. I found fitting the five-minute window into my day to be manageable - and repeatable. 

I later moved up to 10-minute sessions as part of an app-enabled curriculum. The meditation became a transition between different parts of my day to recover focus and energy. I hear that master practitioners meditate for an hour each day - such is the best practice. But if I can get half the benefit from one-sixth of the time investment, I can build a consistent habit. 

Shrinking scope enables consistency. In my experience, sustaining small habits done frequently will trump doing bigger things done once in a while. It's a harder sell to ourselves psychologically: often, the difficult part is just getting off the mark the first time. We ask, "if it is this much trouble to start, why not take a big swing?" But if we permit ourselves to do it small, we create the space to do it again. And that's the critical part - repetition leads to consistency. We can always grow the size of the initiative later. 

Share

Habits can even be valuable when they shrink. In recent weeks, my morning pages shrank rather than grew. Increasing time pressures made completing all three pages a challenge, and my brain wanders to the next phase of work - like editing this essay. But even at the again-reduced size, the bit of writing in the morning continues to provide value every day.

Another great way to go small - and go "wrong" - is to allow elapsed time to do the work for me. Processes that take some extended period can be to my advantage. For example, allowing a Google Ads campaign to play out over time at a relatively throttled dollar amount will generate helpful information when I come to check on it. 

Elapsed time rewards patience rather than hustle; the initiative needs time to bear fruit. And while it might reward occasional review and a little tending, it is more productive when you let it elapse while doing something else. This relationship is true of all initiatives that create value "while you sleep." 

Consistent small habits and leveraging elapsed time have power if you develop them. The ability to have experiments working for me while I focus my energies elsewhere makes me feel like a farmer: I till the field, wait and reap. The land and the calendar do much of the work for me.

Social pressures push the other way. Many founders and would-be entrepreneurs have stories about seemingly super-human efforts and wild successes popping to the top of our newsfeed or social media. We read well-meaning tweets and posts on the importance of "hustle." The intended meaning is as a call to action. But "hustle" often reads as a reward for looking busy: the antithesis of the patient, compounding efforts discussed above. 

One needs a clear idea of value to penetrate these social pressures. People attempting an entrepreneurial venture for the first time often want to "do it right" and so go down a path that nobody could call "wrong." These pressures lead to activities that "look like" entrepreneurship. I quit my job! I'm building a product - here's the daily update! I went into debt! However, the many experiments that need to be "wrong" to find one's north star and the investments in building consistency required to reach it are missing. 

To have a clear idea of value, one must understand the domain one is entering. When one does not know the goal, social pressures mount to "not be wrong." But when you have greater confidence in your objective, doing "wrong" and "dirty" work is easier because you can see how it builds toward your goal. 

Bringing this back to morning pages, I concluded that if I wished to work on more significant ideas, I had better learn to write better. The more words I write - total - the better I would get. In morning pages, I have written over 60,000 words. I credit starting this habit - as small, wrong, and dirty as it was - for this essay series. Sustained writing lets me develop ideas.

What makes "doing it wrong" easier? I see more successes in businesses founded by people with deep domain and industry expertise. Partially, this is because they have repeatedly invested time in being wrong about their industry to find what is right. Those who are more confident in their domain "core" will be willing to take more risks. Seeing where you are confident, and starting there, is playing on easy. 

A second pattern I have seen is taking social cues from customers and the market than from other entrepreneurs. The market is more excited about unleashing value, and the innovative end is interested in risks that matter to them. 

A third pattern that I adopted is getting up earlier. I find it easier to build habits in the morning. When I have time before routine and external obligations set in, I find it easier to create. That's why morning pages are called such - by making them the first activity, they are easier to anchor. 

Nobody gets it right the first time, so we invest time doing it wrong and small first. Form more small habits to build aptitudes. Attempt more small experiments to learn more. 

Do it fast. Do it wrong. 

And do more of it. 

Thanks for reading Sustained Writing! Subscribe for free to receive new posts and support my work.

My thanks to the community at foster.co for editorial feedback. As always, errors are my own.

Photo by Daniel Cheung on Unsplash

The Fifth Source of Capital

"Equity, debt, revenue and sweat"

This rhyme reminds us of the four kinds of capital that drive a business. Most financial products for companies are one or some combination of these four. Most entrepreneurs use some mix over the lifetime of the business. But do we use them well? 

Equity is a claim on company profits and residual assets after paying the creditors. One "raises" equity by selling part of that claim to outside investors. Because it is junior to other claims, this money is usually the most expensive for a startup - which means it's the worst deal for the founder. To raise more funds, founders give up more of their claim to the rewards of their efforts. The press often celebrates raising equity. To my mind, this is nuts. 

Debt is a claim on the business that one must repay. The main block is often the willingness of the lender to issue a loan at all to a startup making software or SaaS. They see an applicant with few assets and a scant track record. They face a legitimate challenge: how does one manage default risk? An often-undesirable way of addressing this underwriting problem comes in credit cards, which charge (usurious) rates for unsecured consumer credit. 

True bootstrapping uses revenue as capital; cash - ideally presale or advance payment - from customers supports overhead. Income is generally the cheapest form of funding on this list. To move it forward, prepayment by early customers - even for a discount - is one of the healthiest ways to get early funding. 

"Sweat" is investing one's time in the business. Outside income, personal debt, or a reduction in lifestyle are what fund this time. The outside income is often the "day job." When people talk about "self-funding," this is usually the mechanism.

The relative perceived costs of these sources of capital distort our decision-making. For example, it's easier to "sweat" on the weekend. And some contributions are more natural fits for the off-hours than others. For example, coding in a dark room works well in the wee hours when you decide not to sleep, whereas talking with customers requires working in the daylight. 

Another distortion is the over-use of equity financing. The entrepreneur prefers equity even when debt is cheap. The United States government subsidizes much small business debt, making it even more affordable. Even so, my cohort of entrepreneurs is reluctant to take on that obligation. Part of this is fear of failure: the thought of ruin arising from a pile of debt that they must now repay - or work out in ways that will affect them for years. 

Financial innovation mixes up these four sources to create new products. Revenue-based financing, for example, is debt kinda-sorta secured by revenue. The resulting product can behave much more like equity in aligning incentives while being lower-risk for the investor. This broad area of "alt-finance" technology is a field in which I invest.

But beyond the realm of financial engineering, there is a newer, fifth source of value available to us in the information age: code. 

The Almanack of Naval Ravikant opened my eyes to code as a source of capital. At one level, the idea of intellectual property as a durable and financeable asset of a business is not new. Indeed, a classic question from a venture capitalist speaking to an entrepreneur attempting to sell their equity is, "what is your IP?" 

But code transcends IP. Mere property is inert and is to be traded or exploited. Code is in motion, executing operations and creating enduring value autonomously and with near-zero marginal cost. 

What makes this new is the ratio of automation to work required to build it (labor) and execute it (capital). No longer do we need to construct iron foundries - code runs for micro-pennies. Build your machine on the cheap, then let it do the work almost for free. 

Ray Dalio at Bridgewater Capital writes about this strategy at length in Principles. He turned each insight learned through (often brutal) experience into an "another one of those" ruleset. He and his team express this model in company computers to execute in the market - repeatedly. 

The fact that Dalio has been applying this approach for over thirty years means the idea of code as a capital contributor is not intrinsically new. But the opportunities grow greater as information technology simultaneously advances and grows cheaper. 

Code driving value for a business is central to how many people see the software business - especially "software as a service." In one view, this is code running to create value for customers while not commanding the time of the company's staff behind the service. Such a setup can fulfill the promise of "making money while you sleep" - an attribute of return-generating capital. 

Another example is event-driven automation. Services like Zapier and Integromat make assigning decision responses to machines much more effortless. One can implement both the conditions and the recommended action in some mix of code and no-code tooling. The answer to "another one of those" then happens automatically - without marginal labor. 

Even today, advances in technology extend the potential for code to generate returns. For example, AI technologies can elevate this kind of judgment automation from mechanical rules to mental models. Rules are recipes: "if this, then that." Mental models are probabilistic frameworks: "this is similar to that and the other thing, but not exactly." The potential is to derive the appropriate course of action and take on reasonable risks. The applications are not far in the future - but the results can be fantastic. 

Few seem to understand this whole field of using code as capital - and I am still learning. It will change the way companies get built and valued. We will need new research in the market to see how these five sources of capital interact in the coming years. It seems pretty likely that we will need a new mnemonic for this quintet: My start needs work:

Equity, debt, revenue, sweat - and robots! 

My thanks to the foster.co community for their support and helpful feedback on this essay. As always, errors are my own.

Photo by Pepi Stojanovski on Unsplash

Pricing as Storytelling

What do I need, and how much does it cost?

Pricing and pricing pages come up repeatedly as a challenge for innovative companies. Most turn into three to five columns of a number at the top followed by a torrent of bullet points underneath, starting with "everything in the previous plan, plus..." The pages are, in a word, bewildering, and the potential buyer moves on as they cannot figure out which offer - if any - would meet their needs. 

I have observed three problematic patterns in the thinking behind these pages. None of them are easy to solve, but they are essential. 

First, founders do not know where the value is in their products. Worse, many of them act as if figuring out how to use it is up to the customer. The theory is that by providing an open, simple toolset, the customers will discover the value. But this is short-sighted: the product enables value in a context. Unless the customer connects the product to their situation, there is no value creation. An entrepreneur's job involves helping the customer make that connection. Messy pricing pages are often a sign that this is either not understood or not happening.

Second, most software and SaaS offerings have minimal variable costs. The cost of adding one more customer is minimal. We often think of "fair" pricing in terms of a markup over the vendor's expenses, but this frame is not helpful to these businesses. The technical components of providing a hosted service - compute, storage, bandwidth - are very cheap! The founder lacks a cost basis to guide the lower bound of pricing. 

Third, without a theory of value or cost, many founders fall back on advice about pricing pages that focus on presentation rather than value. For example, "show something too cheap and something high-end, so customers pick the goldilocks choice." This tactical approach is insidious because it is easy to follow, luring many away from the more challenging problem: connecting value to the customer.

The question we must answer is, "what matters?" Where does value come from for the customer? You are not alone in looking for an answer: even many big companies do not have a handle on this question.

So let's answer it! Try writing a blog post that owns "what does all this mean?" There could be a real expert marketing play in getting ahead of this to explain why each level makes sense for various use cases.

"Free is where you can tinker, but as soon as you hit meaningful development, you will see our rate limit (or whatever) kick in. That's why starter/professional/middle-tier is for getting deeper into your development, providing the tools you need to do it right without paying for the scale benefits you don't need. 

"It's even good for MVP! Then the scale-up pricing is what you want after you get those first hundred customers / thousand transactions. That's where you get service guarantees and our backing to make sure you stay up."

Telling a story will build trust. Even a short tale like the above can move the positioning from a vendor to an advisor. Customers have more confidence in the company that helps them think through what matters. 

Further, this storytelling exercise will elevate the issues that separate high use from non-production use. For example, many SaaS businesses are most valuable when customers use them as part of a production process. That's where the money is! So high use would be putting your SaaS into a production use case. What do people care about in production use cases? Often, the biggest issue is safety and brand control. 

Safety can come from features, but more often, it comes from support. Can you offer a super-short support turnaround at this next level? Can you put an insurance policy or an audit behind the service? These are not adding more technological surface area or volume: they are about the value of the service as a component of the customer's business or life. 

Before then, they may care most about ease of use to adopt your technology on a partial basis, potentially in parallel to official production use or in its corner of the business. For here, the features most important are about ease of use. 

One of the exciting aspects is that changing tiers does not just have to add features. You can take some away! Those features most useful in the tinkering or partial-deployment phase may be harmful in production. Remove them and make it not just "higher price" but also "for production use." 

Implementation of this storytelling idea will depend on your startup, technology, and - most of all - your market. Start today. Take a stab at writing what matters at each step in the customer's journey. What do you have that drives maximum value for that step? That becomes a psychometric segmentation for pricing that will drive more value.

Figure out what matters in the market and tell them about it. Your economics will benefit, and the value to your customers will be priceless. 

I am grateful for the feedback from the Foster community before publication. As always, errors are my own. 

Photo by Nong Vang on Unsplash

Loading more posts…