As a creative, I like to identify interesting combinations of thoughts, and believe there is a connected-ness to all things. Thus, two seemingly unrelated topics, thoughts, or items can be combined based on the ways in which they are the same, and which they are different. Finding the common ground between two things, to my mind, is the definition of creativity. To this end, two experiences come to mind which I’d like to connect, under the banner of introducing an “open source” approach to things.
By definition, “open source” implies that the source code of a piece of software is visible to those who use the software. Thus, depending on the license the software is released through, the code can be tweaked and modified by the end user, to meet a new need. Open source software is often also developed in the open, which fosters a culture of transparency, collaboration, and trust between those using the software, who are often also the developers of the same. Two ideas in particular resonate for me, when considering open source; the considerations to be made during the development of the software, and the transparency and openness around sharing of ideas, concepts, and approaches.
It seems to be that there are themes and patterns across several areas of life at the same time. What is seen as a recurrence in one area of life seems to come up in others. I’ve noticed this for several months, and this time around the concept of “identifying root causes” is coming up. I’m seeing a gaps which I believe a root cause analysis would fill, as well as sustainable results that would be created as a result of a proper root cause analysis.
Not to belabour what is most likely quite clear, a root cause analysis is the concept of diving deeper below the surface when presented with a circumstance/problem, and identifying the genesis of that circumstance, with the intention to resolve it. This would then prevent the knock-on affects of that root cause, thereby resolving the entire chain of circumstances from the bottom up, rather than from the top (surface issue) down.
Root cause analysis is extremely important in an engineering or product context. When something happens which affects the user of a particular piece of software, it is often more beneficial to identify the root cause and resolve that, instead of resolving the surface-level concern. This is true outside of engineering and product, as well.
There are several techniques one can apply to identify a root cause. One popular technique is the “5-why”. When presented with a statement, ask “why”. When presented with the response to that question, ask “why” again, and so on. Within 5 iterations of “why”, the root cause should at least become evident.
One such opportunity for identifying and addressing root causes came about recently, with the closure of my beloved primary school.
When growing a team, implementing new processes, or even when scoping a new project where you feel you have a clear outcome you’d like to see, it can be so tempting to tell yourself that you “just wish the team could read your mind”, or that the team would just “know how to follow the process” or “know what to look for during code review”. The part that’s often left off of these thoughts is “without me needing to explain it”, which is often the starting point for where our thinking falls short. Turning your team into mind readers is very possible, though. Lets unpack how. Spoilers; it starts with you.
We live in a very busy world. As small as we’re perceiving our world to be in many ways (eg: communicating across the globe in an instant, being able to keep track of friends and family regardless of their location, getting instant insight into the worlds of others, and sharing insights from within our own world), the inherent busy-ness of our world is almost undeniable… yet we don’t always acknowledge this cost we’re incurring, in exchange for these “luxuries”.
A large part of this, for me, is this sense of having to “keep track” of multiple channels. These, in essence, all function the same way; “receive messages”, “process messages”, “send messages”. I’ve been thinking about this a lot, lately, and want to begin applying a stricter approach to how I deal with my various “inboxes”, and defining what my list of inboxes looks like.
Every so often, I hear a story which makes no sense. “We put a huge popup banner on our website, and our sales increased by 15%”, “we slowed down our website, and our sales funnel converted 2% better”. While these sentences may make technical sense, they’re odd to wrap one’s brain around, as they shouldn’t make sense. To me, this comes down to a delta between doing what works and the customer’s experience overall with your store, brand, and/or product.
“Jobs to be Done” is a framework often used for making effective product decisions. The intention is to understand what your customer is “hiring” your product to do. For example, we hire our email client (Outlook, Gmail, etc) to provide clear and easy access to our email. If that ever stops happening, we’d hire a different app to do the same job. I like to equate the “job to be done” with the “expectation of an outcome”. In many cases, performing service successfully hinges itself on a specific expectation and outcome.
Getting this right, to me, is the key to successful customer relations, and gives a nice amount of free public relations benefits in the process (tl;dr: customers love your company).
I’m someone who enjoys gathering as much information as possible on a topic, as I enjoy the context. Practically, this often translates to picking up a new podcast (for example) and starting right at the beginning (even if there are hundreds of episodes). I feel this helps to provide context for where the podcast began, how it has evolved, and the knowledge and experiences gained along the way.
In many spheres of life, we often spend a lot of time analyzing and focusing on who/what we perceive as “our competition”. This can be in business, in social circles, and almost anywhere. I believe there’s always room for one more, and competition can actually be very healthy for everyone involved.
As I write this, I’m sitting at a Bootlegger Coffee Company in Cape Town. Bootlegger opened up almost out of nowhere, with a few stores across Cape Town, in a style reminiscent of a Starbucks (dark leather, good coffee, free WiFi, and a food menu). This is not too dissimilar to other coffee companies in Cape Town; Seattle Coffee Company (I wonder how they came up with that name), Mugg ‘n Bean, and Vida e Caffe. When Bootlegger first opened, I heard two main schools of thought; “how are they going to survive as a business” and “this looks really exciting, yet it’s nothing new”.
When making decisions, I’ve found it can be quite easy to get into a “bikeshedding” scenario, where the deciding parties lose track of the actual decision to be made. This can be internal, or within a group. Something I’ve found particularly useful and interesting recently is to acknowledge what we already know and how we already feel, as a way of helping the decision to progress to the next step (towards ultimately deciding).
I spend a somewhat regular portion of my time answering questions around scalability with WooCommerce. Questions such as “I have a catalog of 600k products, can WooCommerce handle that” and “how many orders can WooCommerce handle” are not uncommon. That said, an interesting post by Chris Lema around scaling WooCommerce brought to light a metric I’ve long felt to be a worthwhile metric for measuring overall performance of any online store; “add to cart” events. This metric is great for measuring not only how well your store performs as you receive more traffic, but how well your store is performing overall as well.