Final part, thank God, of my old abandoned book project on language learning. Other parts + context here.
What else will I dredge up from my archives? Can't wait to see!
Part IV of my abandoned book on learning languages. Struck by how much my writing has changed even in the two years since I wrote this.
Previous parts here, including context on where this came from and why it never went anywhere.
Part III of my abandoned book project on learning languages... Parts I and II here. Part I has context on why it was abandoned.
Part II of the abandoned book project on language learning. Part I here...
I've always been a mediocre swimmer. I could never swim more than a lap or two before I was exhausted and needed a break. Even more embarrassingly, I could never submerge my head. I always had a primal fear of getting water up the wrong way somehow, and mastering the mechanics of breathing in time to my stroking seemed beyond me.
In short, I always wanted to learn how to swim properly, but didn't know how to improve. Swimming more laps didn't seem to help, and I just wore myself out faster. I also didn't have the money to hire an instructor and wasn't thrilled by the idea of taking classes anyway. It was obvious I needed some major tutelage but I wasn't sure a class was the way to go.
I read about Total Immersion on Tim Ferriss' blog and always wanted to give it a try. It seemed to be exactly what I needed: a relatively inexpensive multi-media program that promised to decrease my swimming drag, allowing me to go farther with less effort and far more gracefully than before. The fact that it was recommended by Ferriss made me trust it and want to try it more than I would had I stumbled across it on my own, as Ferriss' whole schtick is accelerated learning. The only issue would be finding a swimming pool, as I didn't have access to one.
A college friend and I, both interested in product design, recently challenged each other to begin keeping a "bug list". This is an idea we'd read about in a book by some of the founders of Ideo, the famous product design firm. A bug list is where you keep a list of all the problems you encounter or run into on a daily basis. The problems that seem the most promising become fodder for later product ideas. All good products start with a problem they're trying to solve. The bigger the problem (I've heard it described as solving shark bites versus mosquito bites) and the more people who have that problem, the more impactful the product will be.
More fundamentally, the bug list is a tool to get ourselves in the habit of looking for problems to solve. Everytime we complain, get frustrated, lose something, etc. during the day we make a note of what the problem was. Or I would sit down at the beginning of the day and think of ten or more problems I had as I mentally ran through my routine or through the previous day's activities.
The nature of our challenge was to each come up with ten new problems a day for two weeks. Then we would have a call to compare and figure out the best problems we would like to solve. That's close to 300 problems we came up with between the two of us over those two weeks. Most of the ideas were shit, of course- things that couldn't really be solved with products or even software, or that were more personal problems or societal problems. Or problems that would require a multi-million dollar research team to solve, rather than two young engineers working in their spare time. Many of the problems were small problems, too- problems few other people likely saw as an issue, or that were mosquito bites that wouldn't be worth the hassle of using a product to solve. Still, we developed a short list of things we'd like to try and solve at some point.
Even if none of these ideas go anywhere, coming up with them has been a powerful process for me. I see three distinct advantages.
Jealousy is an unfortunate emotion. It consumes us. I feel it still, though less so than when I was younger, when it would burn up inside of me like a wildfire. Now it is more a tiny spark of flint and steel striking, more energize than enervate.
Base jealousy is an aimless wandering of the spirit. It poisons a relationship, as well as our enjoyment of what we do actually have. I don't think it ever goes away. Banishing it and willing it away will only make it return, like a boomerang, to whack the unsuspecting wielder in the back of the head. How does one wrestle jealousy then?
Accept it. Accept it, and eventually transform it.
I want to share a small tip I've been having some success with to help establish a daily routine- something I know is important, but have never been able to do until recently!
I would always set out with the best of intentions, plotting out to a tee how my morning and night would go and exactly what I would be doing. The sequence would spiral out of control like a cancer until I had my first three or four hours of the day plotted. Sometimes I'd even go so far as to plan out the entire day. And these wonderfully intentioned plans and planned routines never worked.
The problem I'd always have was that I'd mess up once and misspend the day. Guilt-wracked, by the end of the evening I'd have realized how unproductive I'd been and "binge-work", staying up till the wee hours of the morning to try and get as much of my backlogged work done as possible. But I never worked well after 2am anyway, and the next morning I'd sleep in and wreck my fledgling attempts at creating my own routine.
Thinking about what is different with my efforts now, I can see that I've had, or am having, a mindset shift away from this self-destructive work-bulemia. And one thing that helped get me there (or maybe a consequence of getting there, who knows?) was to start thinking of my day as a series of "checkpoints", like the save-points in a video-game.
Basically, I've chosen only three hard and fast times for my routine during the day. The idea is simple, and not new at all, but I think it is effective for reasons I explain below.
My three checkpoints are:
Here's why this works for me.
This reduces or completely eliminates the anxiety of having an entire day planned out to the tee. Three simple times to keep track of instead is totally manageable. Once those times arrive, I know I need to drop everything and move on. I suppose I could ignore the deadline, but only having three hard-and-fast times throughout the day makes that seem like a cop-out and like I'm cheating myself. It totally destresses the process for me.
It forces me to focus on what's truly essential for me to feel like I had a good day. I want to write, and really make a serious thing of my writing, but could never make a habit of it. The same with working out. Yet the difference between the days when I do those two things- write and exercise- and when I don't is frighteningly stark. In short, if I got to those two things during the day, it wasn't necessarily a good day but it certainly wasn't a bad day.
Finally, a big reason for my binge-working and my inability to create new habits or routines was really just because I couldn't ever go to bed on time. Voilà my third checkpoint.
I still have a checklist of routine things I want to get done each day that is more than three items- it's at 15 items, actually- but I try not to sweat it if I miss some of them in a day and instead focus on meeting the checkpoints. Because I know that even if I've totally wasted the day up to that point, if I can make a checkpoint, I'm more likely than not going to continue on track and start ticking off the rest of the items on my list.
Like a video-game checkpoint, these allow me to start anew and try again at having a good, productive day. In essence, I have three opportunities each day to turn a bad day into a good one, or at least a productive one. It's like building mini-periods of reflection into the day, mini-sprints of work/recovery that give me the psychological opportunity to renew myself a little bit with each checkpoint.
And even if I don't feel like doing the checkpoint, the bar is set so low that I know the easiest thing to do is just force myself to do it rather than deal with all the nasty regret and guilt. After all, I only have the three real commitments during the day, and they're pretty easy. Sit in front of my computer with Evernote open until 11. Put on workout clothes and walk outside at noon. Go brush my teeth at ten pm. Since motivation usually only comes after taking action, meeting those three checkpoints is like knocking over the first in a line of dominos. I'm back on track for the day and feeling great. Or at least better.
Zan Perrion provides some inspiration here in his book The Alabaster Girl. In it, he recommends a small ritual he calls Vespers, as in vespertine (occurring in the evening). The idea is that at some point before going to bed, we find a few quiet moments to ourselves to reflect and prepare for the next day.
One could imagine that daily Vespers is like a checkpoint in a video game. We are playing the game of Life on the ‘Hard’ difficulty setting, but because we saved the game at that point yesterday evening, because we reconnected with what is truly important, we can always fall back on that point again any time in the future.
Hope you found this tip to be useful!
Dillon Dakota Carroll
I make no secret of the fact that I'm a dedicated (some might say obsessive) reader. To me, writing is the natural output of a lifetime of reading. Hence this blog, both to satisfy my craving to write and to provide a forum for sharpening my writing skills. Even if it's on a blog that no one ever reads (except for my Dad. Thanks Dad!), writing for an "audience" forces me to write better, to challenge myself, to distill my thoughts and to write them as clearly and precisely and beautifully as possible.
As I get more serious about my writing, two key goals emerge. The first is to make writing a daily habit. If I can make writing an automatic part of my daily routine, I'll have taken care of the hardest part of writing. That is, simply carving out time to put words on the page. The second is to systematically improve my writing.
To achieve both these aims, I'm going to be experimenting over the course of the next several months with a series of daily writing exercises. I came up with 15 of them, some culled from the internet and some from the shadowy recesses of my brain. I'll pick one each day to do in the morning after waking up. I have to do all fifteen before starting over, so in each month I'll go through the list of exercises twice.
Here are the exercises I'll be doing. I'm excited about them because I know they will stretch me to improve my writing in new ways. I already began this morning with the "freestyle poem." Anyway, I hope that the output of at least some of these will be worth sharing here on this blog. If you see any unusual content here that seems out of the norm for me, you'll now know why!
15 in total, repeat twice each month!
"I just don't think you all are going to make it. You're not in wheelchairs yourselves, so how can you know what a wheelchair user wants?"
That was the gist of what a visiting oil and gas entrepreneur told my business partner about our social business startup, which as you can probably guess, aims to create innovative products for wheelchair users.
The problem with his statement is that if true, it completely invalidates the field of social entrepreneurship.
I don't think he was right. As I'll explain, social businesses work because they have the same engine under the hood as a traditional business: a way of bringing in revenue in a repeatable and scalable fashion from customers, or a business model. I'll also explain how, with the right mindset and methodology, social businesses can thrive even without being their own customers.
You can scratch other people's itches too
But first, let's talk a bit about why we hear this oft repeated advice so much. The writers of Rework, Jason Fried and David Hansson call it "scratching your own itch". Generally, this is great advice. If you're your own customer, figuring out how to make your customer happy starts with making yourself happy! As Fried and Hansson point out, for example, Nike was started by a track coach who wanted better running shoes for his team.
Heavenly Bread: A Social Business Case Study
Social ventures can also be a great example of this. Heavenly Bread, a social impact bakery in Tulsa, Oklahoma, had a dual-fold social mission. The first was to provide fresh, nutritional, and preservative-free whole-grain bread to the community. The founder loved her bread and wanted to share it with the community- she is a perfect example of her own customer in this sense.
But let's look at the other side to her social mission. Appalled by Oklahoma's exceedingly high rate of female incarceration (the highest in the nation, in fact) and the difficulty of reintegrating into society after incarceration, she decided to have an open employment policy. And in fact, her first employee was a formerly-incarcerated woman. Let's call her Jane.
While technically the founder's employee, from the perspective of a social business, Jane was receiving a service from Heavenly Bread. Heavenly Bread gave her a job when nearly no-one else would have. The company was attempting to provide a certain segment of the population (formerly incarcerated women) with a socially-impactful service (a steady job they likely couldn't get anywhere else, and without which would likely return to jail). Having never been jailed, the founder was not a member of this population segment.
Despite not having lived the same experiences as her formerly-incarcerated employee, the founder was successful in providing the service to her. After perhaps a half year of working with Heavenly Bread, Jane successfully transitioned out of her job there and into a new company. She likely wouldn't have been able to gain the job without her experience at Heavenly Bread, which helped Jane psychologically transition back to society but also gain the post-prison work experience a potential employer would want to see before hiring her.
So here we have one company that has elements of both kinds of organizations. They are their own customers from the bakery side, but like many social businesses, they also tried to help improve the condition of a distinct segment of the population of which they were not a part.
Build products your customers want to buy
The goal of any new business, social businesses included, should be to find paying customers as soon as possible. This is the feedback mechanism that makes businesses so agile. If you think about it, when a customer gives you money it means that they think the product is valuable enough that they would spend their hard-earned money on it. Suddenly, you don't need to be your own customer- you have successfully scratched the itch of someone else. There are follow-up questions to ask (how many customers are there out there? Do you make enough of a margin off sales to cover costs and expand?) but you've done what is without a doubt the hardest part of starting a new organization: creating a solution people are willing to pay for.
Social impact non-profits may be able to stay afloat from donations, but the point of a social business is that the organization can, at the least, become financially self-sustaining through customer-generated income. If you don't have an effective solution to your customer's problems, you're going to find it out very quickly when no one buys the product. And those who do buy the product will gladly tell you what they really think about it because they've got skin in the game- their money. When I work with startups, I always tell them that feedback from paying customers is the best, hands-down. Otherwise, people will lie through their teeth to you about your product to not hurt your feelings.
Getting to the point of paying customers
Getting to a sale (or even a paid beta) is a huge milestone for a new business. But how do you get to that point? And as social innovators scratching someone else's itch, how can we collect quality feedback when we're too early stage for revenue and thus lack that as a feedback mechanism?
The answer: rapid, experiential prototypes tested with a scientific method.
This will be familiar to Agile or Lean Startup practitioners. This section is designed to explain why these principles are important and show some examples of them in action.
Rapid. No one builds the perfect product right from the beginning. The product always changes as it goes from idea to reality- so we want the cost to change to be as low as possible. There needs to be a focus on quick and rapid prototypes so that as we learn new information, it's as easy as possible to build the next version of the prototype.
The faster we build and test simple versions of the product, the faster we learn. The faster we learn, the faster we can adapt to what works, and the sooner we can get to a working solution. The quicker and dirtier the prototypes, the faster you move and the less time and money you waste. Want to know what some of the first prototypes were for the wheelchair lift my startup is developing? Stacked pallets in one case and stacked reams of copy paper in another. You can't get quicker and dirtier than that.
Scientific. We want to build our social ventures on a solid platform of objective data. This means being able to isolate variables and collect data so that as we build our prototypes, we know what is and isn't working and what needs to be changed.
Business plans, a necessary evil, are usually just a collection of guesses about how we think our business, industry and market will perform. Once you start building rapid prototypes, you can take some of these hypotheses and test them to see if they are actually true or not. Really what we're trying to get at with our rapid prototypes is, before we even launch our product or service, how can we prove objectively that we're building the right product?
In the case of the pallet and paper prototypes of the wheelchair lift, we needed to know very early on if wheelchair users wanted to be lifted from the seat while the chair remained on the ground, or if they preferred to have their whole wheelchair lifted with them. So we stacked copy paper under their seats to test the former, and lifted them onto pallets to test the latter. In a day's work, we learned an important insight about how the product functioned that might have wasted months of time had we tried to mimic the actual lifting technology. In this case, all the wheelchair users we worked with preferred to have their whole chair lifted. They felt more stable having the entire wheelchair lifted with them.
This is the core of the Lean Startup cycle I teach in classes and workshops: A hypothesis you need to validate, the experiment you'll validate it with (a quick prototype and metrics to judge them by) and actionable insights. I say actionable because if the results don't change your behavior in some way, it's a bad experiment! Also, many people start with the prototype they want to build and come up with a generic, unspecific or unusable hypothesis as an afterthought. This is backwards, and results in experiments that don't actually put the hypothesis to the test! It's imperative to decide what you want to validate first, and why that's important to know (in other words, how it changes your behavior). Having decided that, you can design your experiment and prototype.
Experiential. I take experiential to mean two things: Experiential prototyping as a process that incubates empathy, and experiential prototypes as a type of rapid prototype.
Let's talk about the process first. By making the prototyping and product development process as experiential as possible, you're empathizing with your customers. In a social business in which you're not your own customer, the more you can empathize with your customer and understand their fears, motivations and desires, the better a solution you can design for them. This is really the core of the Human-Centered Design movement: you're tearing down the veil of "otherness" that separates the product designers from the product users.
In one great example of how to do this, Nordstream tasked their innovation team with developing an app that added value to the sunglass shopping experience. The entire team set up shop inside a Nordstrom store, in the sunglass department. The whole team interviewed until they had a decent idea of what the app needed to be. Then the coders, working at desks they set up around the sunglass displays, coded it in front of their potential users. They could build a working version and immediately turn it over to have it tested. While they were working on the first running version, the rest of the team used sharpies and copy paper to build mockups they could test with customers. That way, the programmers knew exactly what they would build in the first version. I highly recommend watching the video as it's a great illustration of all three of these principles at work.
Other ways to empathize more with customers:
These are just a few ideas, but hopefully they spark some of your own!
You can also make an experiential prototype as a type of rapid prototype. Let me give you an example.
A startup I worked with called Park Ave wanted to build a marketplace for buyers and sellers of parking spaces during special events like sports games and concerts. They had already started building the app, but before they sunk 6 more months into developing it they wanted to know if there was actually a market for it. So they went out that weekend and spent two days at a baseball game series, talking to potential customers trying to sell them a parking spot for the next game in the series.
Notice that while they're not testing the technology (the app that would take months to develop), they are still in fact testing the value proposition of the app (that parking at special events is enough of a hassle that users will pay to reserve a spot in advance). They're testing the experience of using the product. Almost no one cares how whiz-bang the technology is, they care about if the technology makes them cooler in some way. So the most effective rapid prototypes are also experiential in that they get at the root of how the users would feel using a product if it actually existed.
After all, people use products because of how it changes their experience of the world. Entrepreneurs, even social entrepreneurs, tend to equate the value proposition of their product with the product itself, or with its features. That's only half the story. The value proposition is what the product does and why that's important to the user. Does it save them time or money? Does it make them feel cooler or more heroic? It's the experience of using the product that counts- not just usability, but also how the user's experience of the world changes through using the product.
In Park Ave's case, they learned through 3 to 4 cycles of week-long tests that there was not in fact a market for this product. They then pivoted to a new product. Their new idea resulted in a $10,000 paid beta with a major state university, which they are currently in the process of conducting. The point here is that they avoided 6 months of useless programming and product development and learned through a few weeks worth of rapid, experiential prototyping that their product wouldn't succeed. Instead, they're spending their time building something they know their customer wants because they've already been paid for it.
Generally, it's a good thing to be your own customer. Assuming you're a decently self-aware person, there's no customer discovery to be done.
However, this advice shouldn't be taken to the extreme. Social businesses can, and do, succeed and thrive even in situations where the founders aren't their own ideal customer and are scratching someone else's itch.
Because social entrepreneurs use business as a vehicle to deliver social impact, finding paying customers is the ultimate validation that you're scratching the right place and the itch is going away. The key becomes getting to that point, perhaps even in the form of a paid beta or preorders, as soon as possible.
Agile and Lean Startup methodologies are crucial to getting your social business to that point and beyond. Namely, social entrepreneurs should aim to validate their critical assumptions about their business and customers by using rapid, experiential prototyping to test what works and what doesn't work quickly and cheaply, all while building an empathic understanding of the customer's fundamental experience of life and resulting trials and vicissitudes.
Dillon Dakota Carroll
...sees much and knows much