While designing and developing a new product, your team is making a number of assumptions about the people who will use the product, their skill level and understanding of how technology works, and how they conceptualize the task they need to accomplish. The number of assumptions made is multiplied by the cultural differences between yourself, your team, and the end user.

Over the past couple of months, the development team at Ensibuuko has been working on a complete rewrite of the platform they’ve created to help microfinancing organizations in Africa bring a higher level of accountability and security to their record keeping. The goals of this project are to improve the stability, performance, and usability of the product.

To address the performance and usability of the product, our team has embarked on implementing user testing as a means of validating our assumptions and ensuring that the feedback loop between making a decision and validating it is as short as possible.

As we begin to implement this process in our organization, it’s important to consider some of the differences between my experience in North America and the realities of designing and testing products in Africa.

If you build it, they might not be able to come

When I first proposed the idea of testing our nascent product with users, the first assumption I made was thinking we could invite 5–6 participants to visit our office. This is how we ran user tests at Brewhouse and is the method recommended by most practitioners of design sprints.

A benefit of performing the tests in your office is setting up an observation room for your team members. This allows the test facilitator to focus on providing clear instruction and guidance to the participant, while observers can take notes and keep track of how long each task takes using a tool like The Rainbow Spreadsheet.

One of my colleagues wisely suggested offering the people we hoped to invite some money to help with the cost of transportation. With our new allowance in hand, we started calling customers we hoped could help us test the new product.

What we found was that while the cost of transportation was certainly an issue, the crux of the matter was people simply couldn’t afford the time it would take to travel to our office and back.

Our solution: if they can’t come to us, we’ll go to them.

Use the technology the user is most familiar with

Inherent in a user’s ability to use your product is their familiarity with the device with which they interact. Most people who have a computer in Uganda have Windows PCs because that’s what they can afford. I knew tossing a Macbook in front of our users would not only be intimidating, it could also have been offensive.

Another key difference between these two platforms is the keyboard. The average typing speed of the people I’ve observed is approximately ¼ the speed of my Canadian compatriots. Putting an unfamiliar keyboard layout in front of someone can dramatically reduce their typing speed even further. It was important that we try to maximize the familiarity with the input device as much as possible.

Even then, having a similar keyboard might not be enough. Our first test participant, who normally uses a USB keyboard and mouse hooked up to a tower PC, struggled to avoid touching the Windows laptop’s trackpad while typing. Since we were testing product in his office, we were able to circumvent this by connecting his own keyboard and mouse.

It’s also important to note here that most people I’ve observed using computers in Uganda use the pointer to click from field to field. This isn’t always the case, but is definitely a consideration to keep in mind when designing form fields. Fields should be obvious and large enough to make it easy to click from one to the next.

Record locally ‘cause you can’t trust the cloud

There are many options for recording each test session. While working in North America, I’ve found Lookback to be extremely simple to use and generally very reliable.

One of the downsides to not testing with my Mac is the lack of a native Windows app for recording and uploading videos to Lookback. The Lookback app for Mac records the videos locally and then uploads them in the background. On countless occasions the upload has been disrupted due to an interruption in the network connection. Each time, the upload continued as soon as the connection was reestablished.

Lookback suggests using their Chrome extension and self-test links to record tests on a PC. While this is a reasonable approach, the videos must be uploaded immediately. Otherwise, you’ll lose them. I learned this the hard way.

In Uganda, Internet connections are generally unreliable. So much so that Ensibuuko has established a relationship with Airtel allowing them to provide customers with a dedicated APN (Access Point Name). The APN connects the customer’s computer directly to the Ensibuuko server at Airtel. While this provides a more reliable connection, it also limits the connection to the single server. This means the client device can’t connect to other servers such as Lookback’s.

Our solution to this was to tether our client’s device to my iPhone which has a 4G connection through MTN. While this allowed us to perform the test, the connection was still far too slow for the upload to finish in a reasonable time. The instructions provided by Lookback state that uploads will resume if a connection is lost. Evidently, this does not include lost connections caused by putting the device to sleep.

Unfortunately, we lost one of the two user tests we performed yesterday. Next time, we will record the test locally using the Windows 10 screen recording tool. While we will certainly miss many of Lookback’s features such as syncing the screen recording with a video of the user captured through the webcam, it will ensure we never lose another recording again.

Be Prepared

All of this has caused me to remember the motto I learned as a young Boy Scout: Be Prepared. From having fake profiles prepared ahead of time to ensuring Webpack was running to having a backup recording solution saving our test sessions on the local machine, there are so many ways in which our user tests could have been performed better. Thankfully, we’ll have plenty of time to further improve our process over the next few months of the project.

It’s been just over a week since Andrea and I landed in Uganda. My mind is still processing the innumerable observations I’ve made and thoughts I’ve had since arriving in our new temporary home. At this rate, I expect it will take a lifetime to fully comprehend everything I’ve witnessed just one week in.

During an unexpected layover in Brussels, Belgium, we visited Grand Place and enjoyed some fine Belgian chocolate (sadly, no waffles). The next day, we finally found ourselves flying over the Mediterranean Sea and the Northern countries of Africa. Upon landing, a sea of signs—set in Arial—directed us to the customs counters. A few minutes later, we were officially on Ugandan soil.

Standing amongst a throng of drivers was Tonny, holding a sign with “Pat” scrawled in blue pen over his head. Tonny drove us from the airport in Entebbe to our apartment in the Kololo district of Kampala, stopping at the local KFC for our first meal in Uganda. Not exactly authentic African cuisine, but it was just what our hungry bellies needed.

The next day, Tonny brought me and Andrea to Kamwokya Market, a strip of small shops offering local produce and groceries like matooke, posho, beans, and more. We passed on the meat this time around (though the men manning the meat shops did trick me into giving them an inappropriate hand signal), but explored behind the main row of shops where, under dim lights and sketchy scaffolding, we purchased some of the best produce I’ve ever eaten.

We brought the food home and cooked our first somewhat-authentic meal: posho and beans. Posho is a porridge-like substance that becomes somewhat firm and is eaten by hand along with a “sauce” made up of either beans or meat and veggies. It was absolutely delicious.

On Sunday, Tonny brought his girlfriend to our place to show Andrea how to cook matooke. The four of us shared dinner and stories. Later, Tonny’s girlfriend offered us a tray of eggs. They were also very delicious.

Monday was my first day at the Ensibuuko office. Before heading in to meet the team, Corey and Jamal—two Canadian developers who arrived a couple of months before me—took me out for breakfast to update me on the status of the project and to give me a lay of the land. The team, though junior in experience, are full of vigour and drive and are starting to gain some momentum on the rewrite of the product.

On Wednesday, I joined several members of the team to celebrate the birthday of one of our developers, Fredrick. We had a great time sharing drinks and laughs as Fredrick wore the ceremonial sombrero (yes, it was a Mexican restaurant).

The rest of the week was spent familiarizing myself with the product, getting the dev environment set up on my computer, and introducing the team to product briefs. Harriet, a computer science grad hired as a documenter prior to my arrival, has been unofficially promoted to Product Manager in Training and has been doing a fantastic job.

On Saturday, Tonny took me and Andrea to Kabaka’s Lake. We walked around the lake and found ourselves in an area far more poverty stricken than the district of Kololo. The lake itself seemed to divide two completely different worlds; fancy apartment buildings and hotels on one side and tiny shacks and free-roaming livestock on the other.

We walked from the lake to Mengo Hospital where Andrea is now volunteering. The things we saw along the way had a tremendous impact on me. The level of poverty was unlike anything I’d ever seen before, yet perhaps even more striking was the fact that not a single person we interacted with that day asked for our help. Instead, we were met with friendly smiles and handshakes. And of course, several people commented on my beard.

At this point, I’m still processing the things we saw that day. To walk through an area like that is a privilege I don’t take lightly. At times, it was all I could do to hold back tears. My heart breaks for the people who live in that environment every day, from the toddler who grasped Andrea’s hand in wonder to the men and women who have lived this way their entire lives. I am so grateful that the work I am doing with Ensibuuko has the potential to at least begin the process of helping people living in poverty begin to find financial security.

This week marked a major milestone in my life: for the first time ever, I left the continent of North America.

I’ve long had an interest in travelling and spent a good chunk of the last decade flying and driving all over my home continent. From Burns Lake, BC to Atlanta, GA and many places in between, each city brought exciting new experiences and memories I’ll not soon forget.

As great as each of these trips has been, ultimately the foundations of North American cities share more in common than they differ. Consistently paved roads, clear and legible wayfinding, generally solid infrastructure, and — well — safe drinking water.

None of which can be said of the city where my partner and I are currently staying. While paved roads exist most are dirt, street signs are often non-existent, electricity turns off for seemingly no rhyme or reason,¹ and the water is best served post-boiling.

This city, for those who missed the news on Twitter, is Kampala, Uganda.

Home to ~1.5MM people, Kampala is the largest city in a country of over 37MM. For a bit of perspective, the population density of Vancouver — Canada’s most dense city — is 5,492/km² while Kampala’s clocks in at 7,928/km².

Of course population density isn’t the only difference between these two cities. However, when you also consider the state of each city’s infrastructure, cultural differences, and overall quality of life, it becomes clear that we aren’t comparing oranges with oranges.

Not to mention the rest of Uganda, both urban and rural.

All of this is simply to point out one simple truth: Uganda is unlike any country I’ve ever been. And as a designer that both excites and scares the shit out of me.

A couple of months ago, my friend and colleague Boris Mann introduced me to Ed Levinson. Ed is an angel investor who has has been traveling to Uganda every January since 2011 to run umpiring training camps for Kampala’s little league teams.²

Through this experience, Ed “[became] interested in the educational and entrepreneurial aspects of international development” which led to a relationship with Ugandan founders David & Gerald. Their startup, Ensibuuko, provides cloud-based banking software solutions to microfinance institutions.

These institutions — Savings and Credit Cooperatives and Village Savings and Loans Associations — serve sub-Saharan Africa’s 500 million unbanked individuals. Unlike a bank, which in Africa provides its services at rates unaffordable by many people, these microfinance institutions aim to provide people the ability to save and borrow money when doing so with a bank is cost prohibitive.

Like many other aspects of Ugandan life, these institutions lack the infrastructure commonly found in North American financial institutions. Ensibuuko aims to provide that infrastructure and to do so in a way that is native to Ugandan culture.

As a product designer, it is my job to uncover the jobs for which a customer will “hire” a product. Through a discovery process that involves user interviews and discussions around business models and strategy, I try to help founders and product managers understand what their customers need and design solutions to bring that value to the customer. Perhaps I am a bit naive, but I believe a significant portion of our collective understanding comes from a familiarity with North American culture — people, for the most part, work roughly 40 hours a week and are looking for ways to save time and get more done, faster.

Now two days into my time here in Kampala, I realize none of that familiarity applies.

And so, it will be my job to figure out how to apply best practices of product design to the problems Ensibuuko aims to solve. My hope is that the processes and methodologies I’ve learned over the last decade will help. User research, design sprints, job stories, prototyping, and user testing are the tools I intend to use to discover how to design a product for the Ugandan people. I’m sure I’ll have some missteps. Perhaps I will find it difficult to translate processes and skills I cultivated in North America to an African context. My goal is to write and share the lessons I learn along the way for those who will surely follow in my footsteps.

This past month I had the wonderful opportunity to design and develop a Shopify theme for my friends at Rye 51. While a case study will be forthcoming, I wanted to share one aspect of the site’s development that really got my gears turning.

One of our goals for this project was to allow Matt and his team the ability to publish weekly collections featuring interviews and other editorial content. Out of the box, Shopify allows you to display collections of products with a collection name and description followed by a list of products. While this is perfectly suitable for common category collections, for custom collections we wanted to include images of and links to products throughout the long-form editorial content.

To accomplish this, I employed the help of Culture Kings’ Shopify Shortcodes library to create a product shortcode. Using Shopify Shortcodes is pretty simple:

1. Install the Shopify Shortcodes library.
2. Create a shortcode using the naming convention shortcode-NAME.liquid in your snippets folder.
3. Replace tags such as {{ collection.description }} with {% include 'shortcode' load: collection.description %} in your collections.liquid file.
4. Add [shortcode] to the description field in your Shopify admin.
5. Watch the magic unfold.

The Shopify Shortcodes library comes with example shortcodes for FlexSlider, FontAwesome, and YouTube. Looking at these will give you an idea of how the library parses information passed through a shortcode. The basic structure is something like:

[shortcode-name attribute='value']

To create a product shortcode, I started by creating a file in the snippets folder called shortcode-product.liquid. The shortcode I want to provide for my client should be simple, so I’m going to use the product’s handle (or URL slug) in the shortcode, like so:

[product name='product-handle']

To pass the name attribute to your shortcode snippet, we’ll need to capture it near the beginning of the shortcode-product.liquid file:

{% capture productHandle %}
    {% include 'shortcode-render' render:'name' %}
{% endcapture %}

Now, I can use {{ productHandle }} in my snippet to pull in the shortcode’s name attribute and use it to assign product:

{% assign product = all_products[productHandle] %}

From here, it’s just a matter of using the attributes available through Shopify’s product object to display the product’s title, image, and URL.

'<h1 class="title">
    {{ product.title }}
</h1>
<a href="{{ product.url }}">
    <img src="{{ product.featured_image.src | product_img_url: '1024x1024' }}" alt="{{ image.alt | escape }}" />
</a>'

You can add other attributes, such as a float to allow the product to appear on either side of the text or to add more content. I’ve used this same method to create image galleries and fancy block quotes, as well.

Shortcodes are a simple way to give your clients the power to create even more engaging experiences for their customers.

On April 24, 2016, I quit smoking. Unlike most who take up the habit young, I started in my late twenties. It was a stupid decision to start, bolstered by my arrogant belief that I could quit whenever I wanted. Turns out, quitting is tough.

My first attempt to quit was on a drive home from Vancouver to London. Stuck in a car for four days straight was the perfect situation to quit, however my willpower wained about a week after I got back to Ontario.

I’ve tried to quit a number of times since; sometimes trying the cold turkey approach, others with the use of nicorette gum or over-the-counter e-cigs. Each time I would either quit for just a day or two, or at best reduce my intake by about half for a few days.

Sometime before April 24, I purchased a Kanger SUBOX Mini from a small vape shop in Gastown called Vaporologie. While in the shop, one of the other patrons pulled out his phone to show me an app which tracked when he had quit smoking and how much money and time he’d saved since.

I returned home with my new toy, pulled out my phone, and downloaded the Quit Now iPhone app. It’s a simple app that tracks the days since your last cigarette and offers insights and encouragement along the way.

There were some false starts in the early days, but the pain of having to reset my quit date in the app grew stronger each time.

When friends of mine and I went on an incredible two-day hike to camp at Greendrop Lake in Chilliwack Lake Provincial Park, I made the decision to not pack my cigarettes. It was a gruelling 6km hike across four boulder fields and partway up a mountain to get to Greendrop and by the time I got home all I wanted was to relax and have a cigarette.

I went downstairs, lit the cigarette, inhaled, and filled my tired lungs with that sweet, sweet nicotine.

That was on April 24, 2016 and it was the last cigarette I smoked.

Until yesterday, that is.

On August 10, 2016, I got to spend the evening with my globetrotting, skydiving brother for the first time since Christmas. His team are in town this week for an airshow in Abbotsford. Rob and a couple of his buddies came by for a couple of drinks and to see my new neighbourhood. Not long into the visit, someone suggested we head downstairs for a smoke.

And that’s when it happened.

I asked for a cigarette.

It had been 6 months since the last time my brother and I smoked together. A lot of our deepest conversations over the last few years were with cigarettes in hand. The last time (and the first time in nearly a decade) I saw my father smoke was when he, my brother, and I were standing outside of the funeral home having just carried Mom to the hearse.

I can’t blame my brother because I asked for the cigarette. I asked because I wanted one. I had been wanting one for 108 days. I just hadn’t found the opportunity for rationalization until I’d had a shot or two of whiskey in me and my little baby brother next to me. But he didn’t offer, I asked.

After a second cigarette following a walk down to the beach, I went right back to my vaporizer — a new Sigelei 213 I purchased just last week on my 101st day — and have not felt the urge to smoke since.

Last night I sat down, told my partner, and once again felt the pain of resetting my quit date again.

That was on August 10, 2016 and it was the last cigarette I smoked.

During the last phase of a product design sprint, or as part of any product design process, you will want to test and validate your assumptions and design solutions with real customers. Often, you will want to bring your customers into your office in order to perform these tests, but won’t want everyone involved in the project to be physically present in the room while the test is taking place. Complex and expensive systems have been built to allow teams to observe a user test remotely in another office, but you can replicate this experience while also capturing the test to review at a later time with tools found in most modern offices.

This approach will work regardless of the device you are designing for and is made possible through the use of Lookback. With Lookback, you can record user tests of mobile and desktop apps and websites while also recording the user’s facial expressions and eye movement as they use your prototype. These recordings can than be shared and discussed amongst your team and referred back to throughout the design and development of your product.

Though Lookback only supports native mobile testing of Invision and Marvel prototypes or native apps with the Lookback SDK installed, you can record tests of mobile websites or prototypes built with other tools. To do so, connect your device to your Mac via USB and with QuickTime or other screen mirroring application stream the view from your mobile device to your Mac. While you do lose the ability to do eye tracking, you can still record facial expressions using the FaceTime camera on the Mac.

What you’ll need

• Lookback.io
• A Mac
• An Apple TV
• A TV
• A test subject

The setup

To start, download and install Lookback onto your Mac. If testing an Invision or Marvel prototype, connect either service to Lookback and download the appropriate prototype viewer onto your mobile device. If testing a native app, install the SDK.

If testing a mobile prototype or app, connect your device to your Mac via USB and use QuickTime or another app to mirror the stream on your Mac.

Open Lookback on your Mac and the app or prototype you wish to test. You should see a video stream of the user and either the desktop app or site or the stream of the mobile app.

Then, turn on AirPlay on your Mac and select the Apple TV located in the office from which your colleagues will observe the test.

The video of your user and the product you are testing will both be streamed to the TV where your team is observing and taking notes. For bonus points, stick an earbud in your ear and have your team call you on speaker phone so they can prompt you with questions they would like you to ask your test subject (protip: if you’re observing, try not to cause the person administering the test to break out in laughter over your fart jokes).

That’s it

There’s not a whole lot more to say. With a clever application of Apple’s AirPlay and the tremendously useful Lookback testing suite, you can easily observe and capture user tests at the same time.

If you have tips or tricks for capturing and observing user tests, please let me know on Twitter.

I have two blog posts in draft form sitting in nvALT at the moment. One is about my time mentoring students at Red Academy. Another is about the hiking and camping trips I’ve taken over the last year. Add to that another half-dozen ideas that have been percolating in my head for far too long and it all adds up to feelings of disillusionment, discouragement, and discontent.

It’s never been easier to publish writing online. Hell, it’s never been easier to publish just about anything online. It’s not a technical challenge I face. It’s a psychological one.

Truth is, those same feelings apply to a number of areas in my life. I do not feel that I’m living up to my potential, nor do I feel a true sense of what the limit to that potential is. It’s not a matter of talent or inspiration or even time. It’s a matter of discipline. And discipline is born of routine.

In 2013, Julie Zhuo made a commitment to herself to write once a week. Her first post — a denunciation of January — has absolutely nothing to do with her article about Imposter Syndrome that brought her work to my attention. Nor did it have anything to do with the lessons she’s shared from her career on Facebook’s product design team. But that article set her on a path that has enriched not only her own life but the lives of thousands upon thousands of designers around the world, yours truly included.

I have long dreamed that my work would have that kind of effect. That the words I transmit over these wires would impact people the way countless others’ have impacted me. But I’ve allowed fear and doubt prevent me from even trying.

Two weeks ago, I attempted and failed for the second time to complete Shawn Blanc’s Focus Course. Despite the fact that I designed his website and had access to the content well before it was published publicly, I neglected to take advantage and allow it to cause the type of change I’ve witnessed it cause in others. It’s not that I haven’t had the time. With no kids, no pets, and an enviable work/life balance, I have no excuse.

Back when I was recording the Hundred Down podcast, one of the key things that kept me going was the accountability and encouragement from our listeners. Their support combined with that of two good friends gave me the strength to lose nearly sixty-five pounds in a matter of months. When I gave up, it had been several months since we had recorded a podcast. I had secluded myself to a windowless basement apartment and settled in for a long winter.

Save for popping up to post the ocassional offensive joke on Twitter and, more recently, share my experience working with HabitStack, I’ve still been living in hibernation.

While my team and I have been growing and building awesome products, I’ve been silent about the mistakes we’ve made and what we’ve learned from them. While I’ve been learning about and practicing design sprints, I haven’t shared my experience and how this wonderful tool can help people in any industry solve really tough problems.

That’s not how I envisioned my life would be. That’s not why I’ve spent over 10 years publishing my thoughts online. I did it so I could find a community of like-minded people who just want to create something amazing and learn from those around them.

It’s not January, but like Julie I think it’s time for me to make a resolution. I resolve to write and publish something — anything — once a week. It might not be good and it likely won’t be well-received. But if I don’t start fucking up now, then when?

After publishing my Q1 review of my 2016 goals, I was able to sit down with Scott Ward from HabitStack to discuss my strategy and progress to that point. After an hour of conversation, I realized that Scott was able to provide exactly what I needed in order to achieve my goals: guidance, scrutiny, and accountability.

I made the decision that day to personally hire Scott to coach me towards achieving my professional goals, with the hopes that once my Q2 goals had been realized, I could potentially convince Brewhouse to continue paying for Scott’s services. When I communicated this decision to the team, the response I received was even better than I’d hoped:

The company would hire Scott to aid the leadership team in setting goals and tracking progress across the entire business, starting with the leadership team.

Though this meant that I had to wait a couple of weeks before we could kick things off with Scott, I was excited that we would be working on this together. Though team had spent some time back in November setting individual goals and the leadership team business goals for 2016, we had not yet put a system in place for measuring our progress on a quarterly and monthly basis nor established the weekly habits needed to make the necessary progress.

Our team is still working on refining our 3–5 year “big dream”, but the fact that we’re working on it together makes me feel really good about sharing my Q1 review. I believe that through this experience, we’ll become much better at defining and measuring goals throughout our entire business, allowing us to improve the areas where we are struggling and celebrate the areas where we’re succeeding.

Last November, I attended a seminar presented by HabitStack founder Scott Ward in which he explained the difference between two types of work. According to Scott, work that is urgent has a deadline and a perceived risk of loss, whereas transformative work has the potential to permanently raise the business to a new level. Neither urgent nor transformative work is necessarily more important than the other. However, for a variety of sociological and biological reasons we have a natural propensity for favouring work which is urgent.

Scott argues that trying to circumvent our natural bias towards urgent work in favour of transformative work is a lost cause. The mental energy and discipline required to consciously choose transformative over urgent work is too high of a toll for our lizard brains. As such, the solution to the problem of how to focus on transformative work is to make it urgent.

Yearly Goals

This past January, I did something I had never done before: I set goals for what I want to achieve professionally by the end of the year. They are:

• Reach $300,000 in design revenue at Brewhouse
• Add 1 product designer to our team
• Attend 1 leadership conference
• Attend 1 design conference

I set these goals because they all speak to what I hope to accomplish here at Brewhouse: to build the city’s best product design team. To do this, I need to continue growing as a leader and set goals to grow and improve the team.

I set this year’s revenue goal based on what we were able to achieve last year — $121,500 in design revenue from May to December 2015 which, extrapolated for the time I wasn’t here, works out to $182,250/yr. Because our design team doubled part way through the year, our capacity to generate revenue through design doubled as well. Therefore, $300k in design revenue for a year is absolutely an achievable goal. This goal also sets us up to achieve my second goal of adding another product designer to the team. $300k will pay for 2 salaries for the first two or three quarters as we build our nest egg.

The latter two goals are geared more toward my own professional development, in the hopes that by improving my knowledge and understanding of both design and leadership, I’ll be better positioned to achieve the primary goals.

Of course, setting goals for the year doesn’t solve the problem of turning transformative work into urgent work, and that’s where goal-chaining comes into play.

Breaking it Down

During the seminar, Scott recommended setting quarterly and monthly goals which together form the habits that will help us achieve our yearly goals. This is where I believe I fell short.

For Q1, I set the following quarterly goals:

• 19 design iterations
• 2 design sprints
• Research conferences for Q2–Q4

And the following monthly goals:

• Meet with 1 less experienced designer in the community
• Meet with 1 more experienced designer in the community
• Write and publish 1 blog post to brewhouse.io

As you can see from the following screenshot, I did not do very well at following through with my quarterly and monthly goals:

See all of those red lines? Those are goals I failed to achieve. That’s right, I missed almost every single one. I believe there are two key reasons why this is:

1. The connections I drew between my monthly, quarterly, and yearly goals were tenuous at best. Some yearly goals aren’t represented at all in any of these lists.
2. In an effort to set appropriate expectations, I believe I failed to set enough goals to ensure I gained and maintained momentum.

Because there were so few monthly goals, I found I wasn’t checking in on my Trello board as often as I should have. Because I wasn’t engaging with the list of goals, I wasn’t considering them to be urgent.

Now What?

The first question I asked myself when planning for Q2 was whether or not I needed to adjust my yearly goals. Can I still reach $300k in design revenue this year? Will I be able to hire another product designer by the end of the year? Or, am I completely fucked?

After a great discussion about this with Adam Saint, I realized that I could still make this work. It would require some rethinking and refactoring of my strategy, but overall I believe I can still achieve the goals I set for myself this year. It won’t be easy, and will require more planning and discipline than I exhibited during Q1, but it is possible.

To start, I’ve added more monthly goals. “More monthly goals?” you ask? “But, you couldn’t even accomplish the three monthly goals you set last quarter!“ You’re right, I didn’t. However, the hope is that by adding more goals, I’ll be more diligent in checking in on my monthly progress and thus more engaged with what I hope to achieve. And, should I be successful in completing these new objectives, I should increase the likelihood of achieving my quarterly and yearly goals.

Also, I plan to reach out to Scott Ward as soon as I publish this post to get his feedback and also secure his coaching services to improve my goal setting process and to have someone outside of Brewhouse I can be accountable to.

And with that, I am off to write that email.

Update — Apr 7, 2016

After reading this post, Scott offered the following response:

I think your analysis is almost right. You did have too few goals, but I wouldn’t recommend adding more monthlies. To finish off the goal chains, I’d recommend adding weekly goals that contribute to your monthlies. Those short deadlines give you the urgency.

I totally understand what Scott is saying here. By setting weekly goals, you not only create an even greater sense of urgency, you also get the satisfaction of constant small wins. My friend Shawn wrote about this last year:

When we see that we are making progress — even small victories — then it strengthens our emotional and motivated state. We are happier and more motivated at work. And [therefore], we are more likely to be productive and creative.

He then asks us to consider the inverse, where we begin to feel like cogs in a machine. As much as I love working at Brewhouse, there are days where this rings true. Not all the time, thanks in large part to our constant, iterative product design and development process. But, when I’m not dedicated to a project and am spinning a lot of plates, I can sometimes feel like I’m playing a neverending game of whack-a-mole.

Scott and I plan to chat about this over coffee tomorrow; I am sure I’ll have lots more to share over the next week.