Growth Hacking Trello Template

If you read my last post, Growth Hacking = People + Process, then you know I’m a huge fan of Brian Balfour’s process for creating, running, and analyzing marketing experiments.

There are a few documents that are central to Brian’s system:

  • Backlog
  • Pipeline
  • Experiment doc
  • Playbooks

To make it easy for you to get started with The Balfour Method (I just made that up), I created a public Trello board template and accompanying Google docs which you can copy and use with your team.

Grab the templates:


They should be fairly self-explanatory if you’ve seen Brian’s talk, but keep reading for an in-depth explanation of how I use this system.

How to use it

The Brainstorm list serves as a pinboard for your team’s ideas and links to case studies and articles that you can reference during your brainstorm meetings.

The Backlog list has a single card which links to a Google Spreadsheet with all of the experiments that you actually want to run.

Wait. Why not just make a card for every experiment and put the details (status, category, resources) on the back? As your backlog grows to 20+ experiments, it’s really nice to be able to sort by resources required or filter by category.


The Pipeline list contains experiments that you’ve pulled out of your Backlog spreadsheet and are going to run soon. You can move cards up and down to indicate priority. The cards are color-coded with labels to indicate which category they fall under (AARRR).

I also like to add a size code to the title of the card: (S), (M), or (L) to indicate relative effort. It makes it easier to see how much work is on the table and prioritize.

Cards are moved into the Design list when you’re ready to start working on it. At this point, you’ll start crafting an Experiment doc that describes your hypothesis, metrics, and all the nitty gritty implementation details. I prefer to link the card to a Google doc (which you can clone), but you could also put your experiment information right on the back of the card.


The remaining lists are simply for visualizing the remaining phases. Simply drag your cards into the appropriate list according to where you are in the process. New members of your team should be able to dig through the History and Playbooks lists to quickly get up to speed on past experiments and best practices.


Growth Hacking = People + Process

There was a recent discussion on about whether Amazon advertising the Fire Phone on their shipping tape should be considered a “growth hack” or not.

Was it a growth hack, in 1987, when the car dealership put their name and number on the plastic license plate holders on my grandpa’s Buick Regal? Or was it just a clever marketing idea?

There is a tendency to talk about growth hacking in terms of tricks and techniques. I don’t like it. It contributes to the myth that there are silver bullets in marketing.

Growth hacking is not about tactics–it’s about people and process.

Sean Ellis, the man who coined the term, says:

Growth hacking is experiment-driven marketing.

I’d take it one step further:

Growth hacking is experiment-driven marketing executed by people who don’t need permission or help to get things done.

Tactics always evolve. To me, the real sea change has been in who is responsible for growing a company and how they go about it.


Traditional marketing teams are comprised of non-technical people that often rely on developers, designers, and data scientists to implement their ideas. Growth teams, on the other hand, are made up of autonomous hackers that generate ideas and execute them from start to finish.

When hiring for your growth team, a good question to ask is: “After you come up with an idea for an experiment, what part are you going to play to make it happen?”

How far can someone navigate around this wheel without putting items on someone else’s TODO list?

Balfour's Growth Hacking Process

Prior to the mid-2000s, I’d never seen a marketing department with technical talent. Now, every marketer should be technical.

Designer-developer hybrids (what I call ogre-mages) are every bit as powerful on growth teams as they are on product teams. If you can find people that can ship code and make things look pretty, snatch them up immediately! Not only are these people highly in-demand, they’re just rare to begin with.


While traditional marketing teams might appear to operate like growth teams in terms of the channels they use (SEM, content marketing, email, etc.), many are run purely on intuition and conjecture, which can be poisonous. Decisions about what actions to take, when to take them, and how much money to spend are made in the blind or based on what may have worked historically.

Growth hacking is about running experiments, analyzing results, and iterating quickly. And for this, you really need two things:

  1. A method for running experiments
  2. A system for tracking and reporting

Running a single A/B test every third Wednesday doesn’t count! You need a process that enforces rhythm, assimilates learnings, and keeps the people accountable. (I love Brian Balfour’s system.)

So, the next time you come across one of those posts entitled 176 Top Secret Growth Hacks (My Cat Loves #8) remember–these are not growth hacks. At most they are marketing tactics that might be worthy inputs to your growth hacking machine.

Still Kicking

Wow, it’s been forever since I’ve posted a status update! Fear not: I haven’t given up! That’d be silly, right David Cancel?


Back when I was posting here regularly I was focused on building a launch list and testing Munchkin Report’s value prop. I did that fairly quickly and since then I’ve been heads down on product development. When I’m coding and designing, I never want to break, even to write these short updates.

Some stats:

1.) Launch list sign-ups: 103
2.) Leads from resource downloads: 34
3.) Blog posts written: 9
4.) Monthly uniques: ~125

I’m about a week or two away from letting early access customers run amok! I’ve had people on the list email me itching to see the product (one of them is a preschool), so I’m super motivated.

Clearly I have a lot of marketing work to do–125 uniques per month will not cut it–but I felt I was in a decent enough spot to make a push to get the product ready. Marketing is going to be much more fun with a product to point to, for sure. I’ve got some really cool stuff planned.

Lesson learned:

Despite all the awesomeness of Rails and AWS and JavaScript frameworks, there’s still a ton of grunt work you need to do with a SaaS: authentication, authorization, multi-tenancy, transaction email hookup (and templates), timezone stuff, etc. Plan for this!

I suspect this stuff is much quicker for someone who is a full-time dev in their day job and has done these things 100 times, but for someone who doesn’t code everyday anymore, it’s been slow.

What I want to do this week:

1.) Send out a pre-launch email to my launch list with a product update
2.) Send a non-pitch email to my resource list
3.) Keep working on the dev tasks required for early access to begin
4.) Hopefully get some responses from 1.) and setup calls with people who want in
5.) Purchase a PO box (I don’t want my home address in CAN-SPAM email footer)


Accelerating Boostrappers

I believe that the bootstrapper community would greatly benefit if individual founders joined forces, Voltron-style.

Let me explain.

If you hang out in bootstrapper circles–places like MicroConf, BaconBiz Conf, or–you’ll find plenty of smart, talented, and highly-motivated entrepreneurs trying to build SaaS businesses on their own, in their spare time, without much cash.

Inspiration comes from likes of Patrick McKenzie (Appointment Reminder), Ruben Gamez (Bidsketch), Rob Walling (Drip, HitTail), and Garrett Dimon (Sifter), each of whom has reached escape velocity with their startup. But for every Ruben Gamez you’ll meet 100 skilled bootstrappers who are scratching and clawing just to ship something, anything.

Unfortunately, the likely outcome for a bootstrapper is burn-out, dwindling interest, or perpetual “side-projects.” In other words, failure. (Other times we fail for the same reason funded startups fail: nobody wants what we made.)

What is success to a bootstrapper?

It is not building the next Facebook or Twitter. We don’t raise venture capital because we don’t want lots of employees, a board, and pressure to exit. We’re not aiming for the fences. We’re looking for what the Valley often calls singles and doubles.

Bootstrappers usually want the following two things:

1.) To earn a fantastic living 2.) To build and sell software products with people we love and respect

The accelerator approach

I’m not suggesting, as some people have, that solo-founders team up from the start as co-founders. Instead, I propose that we turn mastermind groups into mini-accelerators using the Idealab model (as opposed to the YC or TechStars model).

Companies within Idealab are malleable. The founder, Bill Gross creates, modifies, and kills companies as he gains information about which ones are likely to succeed. More importantly, it’s not a winner-take-all system. Rather, the whole of Idealab is enriched when they produce a successful company.

Translating this to bootstrappers: in a mastermind, when one of the members starts getting serious traction with their product, 1 or 2 of the other members can elect to sideline their own products and join the promising one in hopes of making it a winner (where winner == a small, highly profitable software business).

Check my hypothetical math, but $60,000 in monthly recurring revenue (MRR) with 3 highly-talented entrepreneurs seems much easier to achieve than 3 highly-talented entrepreneurs trying to achieve $20,000 MRR on their own.

But how in the world is this a good idea for the original founder? Because growth and success for a bootstrapper can be excruciating at times–specifically the times at which you would typically raise and deploy venture capital.

This slide from Garrett Dimon’s amazing talk Bootstrapping a Software Product sums it up nicely:


If the founder can short-circuit the “most challenging time of my life” leg of the journey and share his/her success with 1-2 like-minded bootstrappers, that’d be awesome!

The cap table shouldn’t really matter because of the no-exit premise, but you could do a 50/25/25 split. Again, the goal isn’t to build the next Oracle (God help us), but building the next 37Signals or Balsamiq or Panic would, in my mind, be a net-benefit for the world and help more micropreneurs reach the ultimate goal of earning a fantastic living building software on their own terms.

This is merely a thought experiment, but I would absolutely love to hear your thoughts in the comments below!

Sidebar 1: The podcast Our Own Little Accelerator sparked the idea for this post. It’s essentially a recorded, published mastermind session. It’s awesome! A few episodes in, it had me thinking, “Wow, if a few of these guys just joined forces and worked on one good idea, they’d be wildly successful.”

Sidebar 2: For more on Bill Gross and Idealab, check out this fantastic interview on This Week in Venture Capital.

My Struggle with Ruby Blocks

My name is Rob and I had trouble understanding Ruby blocks.

This is my story.


Oh, hey, here’s a simple example of a block in Ruby:

display_name do
  puts "Rob"

Wait, why not just do this:


Oh, I see, because display_name doesn’t want to decide how to display my name. Instead, it wants me to supply the line of code that does the displaying. Three cheers for flexibility!

Let’s add some comments to illustrate this difference:

# I'm passing a block of code for display_name to run
display_name do
  puts "Rob"
# > Rob

# I'm passing a value for display_name to use with its own printing code
# > Rob

But I don’t really understand how display_name runs my block of code. Maybe it’ll make more sense when I look at the method definition:

def display_name

Hmm. That method definition doesn’t exactly scream, “Yo, I take block of code and run it!” There’s no argument in the method signature that accepts my block, and I don’t see anything that actually calls my code either.

Hidden in plain view

After some digging, it turns out ANY Ruby method can invisibly accept a block and the yield statement illustrates the calling of the given block (at runtime my code goes right where that yield statement is).

Wow, that’s TOTALLY not obvious.

There’s an alternate–and more explicit–way of defining such a method:

def display_name(&block) if block

Above, there’s an argument in the method signature that indicates that there’s a block of coding being passed in and explicitly called. There’s even a check to make sure a block was provided!

Despite its clarity, nobody uses this pattern because it’s slow and Rubyist tend to favor brevity.

OK, achievement unlocked, but the example above is too trivial. It doesn’t illustrate what blocks are good for. Let’s modify it slightly:

def display_name
  puts "I'm about to run your code..."
  puts "That felt good."

The method isn’t much more useful, but I kinda-sorta see where we’re going with this. The method can do all sorts of things before and after it runs my block. I’m starting to see blocks as a form of code injection.

Putting on my big boy pants

I’ve got this now. Let’s do some Rails!

@product = Product.find(params[:id])
respond_to do |format|
  format.json { render json: @product.to_json }

OK. Based on what I know, I’m calling respond_to and passing it 2 lines of code to run, which are:

format.json { render json: @product.to_json }

But what is format? Where does its value come from and why am I calling methods on it?

Is format an argument to respond_to?

<< scratches head >>

No, that would look like this:

respond_to(arg) do |format|

Or as we Rubyist are accustomed to:

respond_to arg do |format|

Turns out that format is an argument to my block. Its value is passed (or yielded) to me by the method I’m calling.

Let me phrase that differently: I’m calling respond_to which does some stuff and then passes my block a value held in the variable format.

Right, but what is format? What can I do with it?

respond_to do |format|
  # Umm...

A minor epiphany

Here was the major realization I had about blocks: without understanding the inner-workings of the method I’m passing a block to, I can’t really write my block.

I couldn’t treat it as a black box, as badly as I wanted to. With many methods (or APIs), I can simply pass in arguments and get a return value without ever having to understand what actually goes on inside. And that encapsulation is a beautiful thing.

But with blocks, I am actively participating in writing the method I’m calling, so I have to understand the context in which my code is called. I also have to understand the objects that are yielded to my block via its arguments.

Let’s play detective:

respond_to do |format|
  # What is format, really?
  logger.debug format.class
# > ActionController::MimeResponds::Collector

I’m calling respond_to and passing it some lines of code to run. My block is given a Collector object to work with via the variable named format.

Now I can look at the Collector class and see what methods I can call (such as html and json). Ah-ha!


I’d be remiss if I didn’t touch on iterators. See, in Ruby, blocks are also used quite frequently to iterate over collections:

food = %w{apple orange grape coconut}
food.each do |f|
  puts "I like to eat #{f}"

Armed with my knowledge about blocks, this code is super-easy to understand!

I’m calling food.each once and it does all the legwork required to loop through the array which called it (i.e., food). Every iteration within each executes my puts block, passing it one of them items from the array via the variable f.

And that’s all there is to it! :-)

Comments? Questions?

Did I miss anything? Veteran Rubyists dying to tear me to shreds? Leave a comment below.

Entrepreneurial ADD

What I did this week

  • Published blog post 3 Sleep Training Books You Can’t Live Without and promoted to FB, Twitter, Pinterest
  • Commented on 2 parenting blog posts and linked to the above (and I’m actually getting some traffic as a result)
  • Edited 2 blog posts in the queue (with M for final review)
  • Designed a printable child activity sheet with Munchkin branding which I’m going to give away for free
  • Created a resource center and added the daily activity sheet to it
  • Created a MailChimp workflow for delivering resource downloads in exchange for email addresses (this was harder than it should be)
  • Attended the HubSpot Inbound conference in Boston

Traffic to the Munchkin Report sales page and blog is still pretty much non-existent. I wish I could move faster, but I’m somewhat pleased with the above.

On the Mastering HubSpot book front, I did a lot of word-of-mouth promotion at Inbound.  I’m feeling good about the ability to promote the book through an existing channel, but splitting time between writing chapters and moving the Munchkin marketing needle is horrible.

I titled this post Entrepreneurial ADD, which is a term I think I got from Mark Suster. Many entrepreneurs can’t focus on one thing because they get bored too quickly.  I don’t believe that I’m afflicted with E-ADD, though my symptoms are the same. I just think I’m suffering from severe time constraints and I’m spreading my available time across too many disjointed activities–writing, marketing, coding, researching, editing, etc.

I’m quite used to Extreme Context Switching™ from my day job, but doing it after-hours is really hampering the progress of both Munchkin Report and Mastering HubSpot.

I’m seriously considering shooting the book in the head, despite how much I believe in it.

I’m going to run this by my mastermind group this week, but I’d love to hear what you think, so please post a comment!

Next week

  • Link to my daily activity sheet PDF in various forum threads I found where people are asking for one
  • Brainstorm a list of content ideas specifically aimed at daycare directors (as opposed to parents)
  • Begin work on “X Most Influential Parenting Blogs”-type blog post (holdover from last week)
  • Send a nice email (asking for nothing) to 10 semi-popular, non-A list, parenting bloggers (holdover from last week)

Segmenting a MailChimp List by Signup Source

I love Nathan Barry’s post on how he does email marketing. One small, but important, detail that I picked up the second time through the post is that Nathan keeps all of his subscribers in a single MailChimp list and then segments them down by signup source in order to deliver the most relevant content.

This is an excellent way to structure your list. You could achieve the same result with separate lists for each signup source, but that will become unwieldy when you want to send a single campaign to multiple lists, or to your entire subscriber base.

So, how do you capture signup source?

It’s really easy! Login to MailChimp and click on Lists in the left nav and then click on your list name. Click Signup Forms and then General Forms.

Add a hidden text field called SOURCE with a label “Signup Source” and a reasonable default value (in case you forget to pass one). Save your form.


Notice how I put the merge code *|SOURCE|* in the header of the signup form as well — this essentially lets you call your list something different to people signing up for different reasons versus settling on a generic name and potentially confusing people.

Now, wherever you embed your form, simply add the following line of HTML right above the <div> that encloses your submit button:

<input type="hidden" name="SOURCE" id="SOURCE" value=" Newsletter">

Obviously you should change the value parameter to whatever you want that signup source for that form to be.

That’s it — now you’ll have an extra property on every subscriber record that indicates which form they came in on. If you’re capturing email addresses with multiple different incentives, this extra bit of data is vital.

Building Traffic From Scratch

This post is part of a series which chronicles my attempt to bootstrap two products: a SaaS called Munchkin Report and a book called Mastering HubSpot. 

Last week’s post titled Building Software in Public yielded a great response from the startup/bootstrapper community. The post briefly made it to the front page of Hacker News.

The result:

  • 2,450 new visitors to
  • 87 new RSS subscribers to
  • 594 new visitors to
  • 8 new members on the Munchkin Report early access list

While Hacker News readers clearly aren’t the target audience for my products, this is still a positive thing.  I hope some of these visitors follow along and learn something; plus, the more people that know about my products, the better.

A number of people emailed me or posted comments cheering me on and offering feedback and advice.  A few people even said they can’t wait to start using Munchkin Report with their families!  Thanks to everyone who chimed in.

OK, now back to business.

What I did for Munchkin Report this week

  • Published a new blog post and promoted to Twitter, FB, Pinterest (8 pageviews)
  • Retweeted some parenting articles from @munchkinreport
  • Followed some more relevant accounts on Twitter and Pinterest
  • Sent a guest post to
  • Drafted 4 new blog posts
  • Launched a $10 paid discovery campaign on StumbleUpon (cost so far $5.60, visits 25, conversions 0)

Publishing quality content that nobody reads sucks, but you have to do it.

Building an audience from scratch is, in my estimation, one of the hardest things about bootstrapping.  As you can see, it’s slow going right now, almost depressingly so.

But we’re going to keep plugging away, posting and promoting the best blog content we can possibly muster up, even though it appears futile right now.  This will pay off, hopefully, in a few ways:

  • In the long run, if we keep publishing content strategically (i.e., paying attention to keyword difficulty), we’ll eventually start getting that steady trickle of reliable organic search traffic to each post
  • If we do have a hit post, people will be able to work backwards and read the stuff that was written when no one was watching, which will increase the likelihood of making them a fan
  • Having quality content published will increase our chance of scoring guest blog posts

Some resources I’ve used

StumbleUpon Paid Discovery

I launched the paid StumbleUpon campaign on a whim.  There’s no good reason for choosing this over AdWords or Facebook other than how fast it was to setup.

Like Facebook, SU lets you target a demographic.  SU’s dashboard tells me I got 40 paid visits, but Google Analytics only shows me 25.  Not sure why this is, but it’s probably worth an email to SU to find out.


I’ve only spent $5.60 so far and my cap is $10.  I realize this is probably not a large enough spend to get a significant reading on whether or not this could be a viable acquisition channel, and for that reason, is probably a waste of money.

I’m also debating whether I should send people to the blog or a landing page with a specific incentive (e.g., potty training guide) in order to capture their email address.

At the current cost-per-visit, I can spend $140 with SU and get 1,000 visits in the parenting/babies demographic.  At some point, I’ll do a Facebook vs. SU vs. AdWords challenge and allocate $100 to each and see what happens.

Next week for Munchkin Report

  • Create and publish a free printable daily activity sheet PDF with Munchkin Report branding (holdover from last week)
  • Edit and post 3 of the 4 blog posts in the queue
  • Follow-up with on guest blog post
  • Begin work on “X Most Influential Parenting Blogs”-type blog post
  • Send a nice email (asking for nothing) to 10 semi-popular, non-A list, parenting bloggers

What I did for Mastering HubSpot this week

  • Made 2 new connections that can help me with promotion
  • Did some research for my analytics chapter
  • Finished creating a tool that’ll be packaged with the book

Next week for Mastering HubSpot

  • Attend HubSpot’s Inbound conference (just for a day) and get feedback on the book

Helping others

The highlight of my week was actually the 3 phone meetings (4 if you count my Mastermind meeting) I did with fellow product people to impart some advice and feedback on their current projects.  This reminded me of a great blog post by Joel Gascoigne of Buffer:

When we were making just $20 per month with Buffer, I had the feeling that I couldn’t help people: I wasn’t successful yet! What I’ve found, however, is that I could help far more people when I was at that stage. I believe you can too, whatever stage you’re at.

Email me or post a comment if you have any questions or feedback.

Also: should I split Mastering HubSpot and Munchkin Report into their own posts?  Let me know.

Building Software in Public

I’ve been relatively silent about my SaaS side product, Munchkin Report. Well, that’s about to change: I’ve decided to post everything I do—marketing, sales, customer development, engineering, etc.—publicly here on my blog. Let’s see what happens!

This is a big step outside my comfort zone.

Then why do it? Well, because every time I see someone open up their books (Patrick McKenzie, Pat Flynn, Nathan Barry), their candor only accelerates growth.

So, here goes nothing…

Munchkin Mascot

Current status

I launched the sales site a couple of weeks ago and I’m trying to build an early access list and generate traffic and buzz while continuing to work on the application (which is about 60% code complete).

I’m building an audience from scratch with the help of my wife, Melissa, who’s my co-founder and an extremely talented writer with lots of great things share with our target audience of busy parents. She’s our secret inbound marketing weapon.

I will not write any more application code until I have at least 50 people on the early access list.

My biggest obstacles

I have a fairly demanding day job, which I really enjoy. I’m a marketing director for a fast growing software company and I manage a team of people, and I refuse to let my side projects interfere with my full-time gig. I also have a fairly busy family life, so I’m lucky if I can eek out 6-8 hours of work per week on Munchkin Report.

Despite being stretched dangerously thin, I’m simulateously writing a marketing ebook called Mastering HubSpot. I know this is a bad idea, guys.

All of the smart people I talk to say to go all-in on one thing at a time. Focus, Rob! But I’m hoping I can juggle for just a couple of months until the book is done and hopefully yields me a quick win. Famous last words.

What I’ve done already

  1. Coded and designed about 60% of the web application (Ruby on Rails)
  2. Wrote copy for, designed, and launched the sales site
  3. Published 2 blog posts and shared them on social media (to essentially no one)
  4. Created a Twitter account, Facebook page, and Pinterest page
  5. Followed a bunch of relevant people (mostly mommy/parenting bloggers) on Twitter
  6. Began compiling a list of influencers in my niche (with name, email, date of last contact)
  7. Commented on a few relevant blog posts and forum threads to build my reputation/become

Next week

  1. Post and promote 3 more blog posts
  2. Pitch a guest blog post to a couple of target blogs
  3. Create and publish a free printable daily activity sheet PDF with Munchkin Report branding

Stay tuned for more updates, which I hope to publish weekly.  I’ll probably do the same for my ebook.

I hope this keeps me accountable and also inspires other bootstrappers that are following along to forge ahead.

Status Boards and Company Culture

One the most fun and useful things I’ve ever built is the Fog Creek Big Board.

Will Thompson, one of Fog Creek’s talented summer interns, cleaned up my hideous code and open sourced one of the board’s neatest components: the Solari board.

Solari Board

Status boards are pretty common fixtures at software companies these days, but, let’s face it, many of them are nothing more than eye candy.  Of course you want your status board to look pretty, but building one that’s indispensable is the real challenge.

Man, the Big Board was soooo useful.

The Big Board quickly became the centerpiece of our customer support workflow. In a way, it was a graphical representation of the Fog Creek customer service philosophy.

I can’t take credit for the board’s success, though. I did much of the design, but the Big Board was the brain child of Rich Armstrong, who is not only a master of process improvement, but has a keen ability (super power, even?) to cut straight to the core of the thorniest technical–and sociological–problems.

I remember the discussion between Rich and I about what we should put on the board. I thought, “What would look cool?” Then Rich said, “So, what behaviors do we want to reinforce?” Ah, yes, of course.

We wanted to:

  1. Respond to customer phone calls according to schedule
  2. Respond to support cases within 1 business day
  3. Reduce our Fix It Twice backlog

And so we added our call schedule to the Solari board, front and center. As soon as a support call was scheduled and assigned, the train board clattered subtly and everyone on the team knew about it.   Calls wouldn’t be missed.

In the upper right-hand corner of the Solari board there was a small digital clock displaying the time our next support case was due for a response, in accordance with our 1 business day SLA.

The color of the clock was highly relevant, too:

  • If there were cases in the queue that were overdue, the clock turned red.
  • If cases were due within our business day window, the clock turned yellow.
  • If we managed to close all the near-term cases, the clock turned green. We called this “greening the board.”

Around 4pm every day, we’d jokingly rib the person that was preventing the board from turning green. Then we’d all pitch in to help, like we were on a World of Warcraft raid, until our mission was accomplished and we could reward ourselves with a beer and random discussion about web frameworks or classic movie references I didn’t understand.

Some days we’d green the board super early, which meant we could take the rest of the day to work heads down on our side projects, only stopping with the clattering of the Solari board.

Lastly, we displayed a raw count of Fix It Twice cases in the backlog. If this number exceeded a threshold we set, it signified that, once our calls and near-term cases were in order, we should trim the backlog before digging into project work.

Incentives: aligned.

These 3 simple indicators, all provided by the Solari board, kept our processes running smoothly and made our customers, and our team, happy.

Ask yourself: What metrics underly my team’s culture?  And how can I make them public, actionable, and fun to affect?

Other posts on the Big Board: