DeveloperTown

It really isn’t that hard.

Asked to make a small change that feels undoable? It’s probably simple…

Asked to design a new feature that you think is too difficult to integrate in your app? Think again. Maybe it will groove just fine…

Ever thought, “I’m sure this code is complicated, so I’ll let my coworker (who probably wrote the code) take care of it”? It probably isn’t complicated…

Ever shied away from learning something because it’s not “what you’re good at”? You’d be surprised…

Ever had an idea of how to change something within your company, but were daunted at the thought of “changing” something? Change is easier than you think…

Obviously not everything is easy. But not everything is hard either. Most importantly, don’t let what appears to be “hard” get in the way of trying something new or accomplishing a goal.

On the 2nd day of my first full time job out of college, my boss sat me down and asked me this, “What should we own?”

I was a little confused and wasn’t sure what he meant.  He proceeded to explain to me a concept that has stuck with me to this day.  That concept is this:

Every company within a given market space owns something (whether that is intentional or not is a whole separate blog post which I will get to at some point).  What I mean by this is that every company has words or short phrases that define who they are.  This concept is commonly known as the word association game.  So, if I say, “Nike,” what is the first word that pops in your head?

So I went through the exercise of giving one or two words to every competitor within our space.  My boss then said, “Great!  Now what should we own?”

At first glance one would suggest that you want to own what your competitor owns because that is the quickest way to turn the tables.  I would contend that going with that strategy is often detrimental to a young company, especially if you are going into a space with a well-defined market and established competitors.  The reason being is that it will take a ton of resources (money, time, people) to overtake that established company.  You will always be compared and identified with that larger company as trying to own the same thing.

Instead, I would suggest that you find your own couple words to own. Let those words reverberate throughout everything your company is and everything that you market to the world.  With every decision you make you should look back at those two words and think, “Does this get me closer to owning that space?”  The better you can become at making those words identifiable with yourself, the better people will remember you and the more you will stand out from the competition.  Then, you will be able to take on those well-established competitors because you aren’t the same as them.  You are different.

A great example of this exercise can be demonstrated when we look at how Indianapolis has really become one of the top cities in the country.  At the time of the Super Bowl I watched a documentary that showed how Indianapolis has evolved into a city that could host an event such as the Super Bowl.  The thing that stuck out to me is that Indianapolis was a city with no real identity, especially when you compared it to the competition of larger cities in the MidWest.

Indianapolis choose one simple word that defined who they were going to be as they tried to change the city: Sports.  And even more specifically: Amateur Sports.  Some thought this seemed crazy and many thought this was ridiculous that Indy would try to identify itself this way, but when you look at the major city landscape, no city had really tried to own this before.  Today, Indianapolis has been deemed by others as the “Amateur Sports Capital of the World.”
And that all started with just one or two words that were different.

So go.

Define your competitors.
Define yourself.
Breathe life into those words.
Reap the rewards.

The three most important factors in creating a business? Risk, risk, risk.

If you try one, JUST ONE, thing that is “lean startup-ish”, try thinking about your startup purely in terms of risk. Sure, Eric Ries taught us about validated learning and Ash Maurya has shown us how to learn from problem interviews and solution interviews. There are lots of tools out there for the lean startup crowd. But the question remains, how can I get started?

By focusing on risk. The principle that both of these entrepreneurs share is that a startup must work hard to minimize risk. Validated learning, customer interviews, lean canvases, innovation accounting…in the end, these are all tools for reducing risk in a startup. Here’s why: the biggest risk in a startup scenario is that we’re DEAD WRONG about our idea and its place in the world. So tools are invented to keep ourselves accountable to the real world.

I’ve been recently pursuing an idea to help K-12 teachers communicate better with parents. I don’t have 40 hours a week to spend on this, and it’s a one man team until there’s validation of the idea. As a result, I need a simple, clean plan for testing my idea. Here’s the process I followed:

Brainstorm Risks

There are a couple facets to my app: it requires parents to sign-up, teachers must produce content, and schools need to pay. Based on these few facts, I came up with the following list of risks:

- Parents and teachers must find value in the app.
- Schools must be willing to pay for the app.
- Parents must voluntarily sign-up to receive communication.
- Teachers must be willing to try the app.
- Schools/teachers must populate the app with student data.

Prioritize the Risks

I then prioritized the risks based on two factores: the degree of risk and timing. The riskiest items must be worked on first. But just as important, I needed to account for timing: which risks do I have the resources to tackle NOW? Based on these two questions, here’s the prioritized list:

1. Parents must voluntarily sign-up to receive communication. (There’s no point to the app otherwise!)
2. Parents and teachers must find value in the app. (Who cares who pays or how many teachers try it if no one values it?)
3. Teachers must be willing to try the app. (I need teachers to voluntarily start using the app.)
4. Schools must be willing to pay for the app. (Extremely important! But I want to test the product before I have to wait 3 more months to get product feedback again.)
5. Schools/teachers must populate the app with student data. (Eventually, but not NOW, I need student data to be populated without me spending hours prodding teachers to do it.)

Often times, the greatest risks are that you’re building something people value and that people will pay for it. Or maybe you’re inventing new technology, and the risk is that it can be done affordably. Or it could be that you need to secure patent rights. But, SaaS products (software as a service) tend to see the same reasons for failure: a poor value proposition or insufficient revenue.

Create a Plan to Mitigate the Risks

In my most unemotional state, I can now view my business as a combination of those 5 risks. If I’m able to mitigate them, then the business should succeed and the money should roll in. But, how do I work towards eliminating these risks?

This is where your planning powers play a role. You must make predictions about what to expect if you’ve effectively mitigated a risk. For example,

If I can onboard 25% of parents for ONE class at ONE school, then I am confident enough to move on to the next risk.

Here’s the kicker: the first few months are more about instilling confidence in my idea rather than scaling a real business. That’s why the 25% number is fairly low and I’m only testing with ONE class. If I can’t meet this challenge, then I need to reset, find a new class, and/or improve my onboarding process.

My second risk is tested in this manner:

If teachers send 20 communications per week to parents, and parents read 75% of them, then I am confident enough to move on to the next risk.

And so the pattern continues, until I have enough confidence to take the business to the next level…

User Stories Suck for the Last Mile

Yeah, that’s right. I said it. User stories suck for the last mile. What’s the last mile you say? It’s a term borrowed from my telco days, when Sprint had a U-verse-like offering that was way ahead of its time and you could only get in Kansas City. It was awesome. But it died, because getting the last mile of networking was proving to be too expensive. The last mile, in this case, was the distance between Sprint’s closest network terminal and your house.

For user stories, the last mile is the distance between the story being functionally complete (i.e. everything works as expected) and accepted (i.e. and it looks the way I want it too). It is often a long list of layout and style changes like “left-justify X” and “make the margins line up between Y & Z”. These changes are often hard to communicate via written words, but more importantly the delay between feedback and development is too long and, since the changes tend to be small, the cost of switching tasks between all the stories that need tweaking can be pretty spendy.

Sprint Reviews Can Make This Worse

If most of your feedback collecting occurs at the sprint review, this only becomes worse because the person recording comments is frequently not the person giving feedback. Usually, one team member takes notes while the other team member demos stories and the product owner(s) discuss changes. As a result, you create this huge backlog of bugs, tweaks, chores, or whatever you call them that you do prior to the stories being accepted and you starting new ones.

Years ago I started a practice of implementing as many of the tweaks as I could immediately following the sprint review while they were fresh in my mind, but it’s still not optimal. Why?

Because the sprint isn’t finished. We walked out of the sprint review with more stuff to do prior to the stories being accepted. This is a bit discouraging, especially if even more problems are found after the initial round of tweaks go in. If you end up going through cycle after cycle of tweaks, discouragement turns into frustration.

“Peer” Programming Works

About two months ago I gave up on sprint reviews. Instead, when I finished a story I simply skyped at my product owners that I was done, even before I pushed my code or marked the story delivered. I shared my screen with them, gave a demo, then they would just type changes at me in Skype, which I would implement in real time. Because we were using IM and screensharing, they could keep doing other stuff while I made the changes. When I was done, I’d IM them back and we’d start over. After a while, the feature was done. I’d push the code, the CI server would update test, they’d give it a final run through and accept the story. Piece of cake.

I call this peer programming rather than pair programming just because only one of us is actually programming, but the peers are giving feedback in real time. It’s very, very efficient, and we haven’t had a sprint review since we started doing this.

Take It Up a Notch for the Big Event

Earlier this week I spent three days onsite “peer programming” with the product owners. We set up shop around a table in the Developer Town offices with my second monitor where everyone could see it and went through the application one feature at a time tweaking features prior to ‘soft’ launching the new product on Wednesday afternoon. It was exhausting, but the end product is totally awesome.

This kind of pre-launch peer programming is a perfect way to efficiently get all the little details right. It’s very effective communication because the feedback loop is super short and the people with questions and answers are together. It’s a lot better than a sprint review because, among other things, the story gets accepted at the end of the session.

Making it Productive

Here are some pointers for making peer programming work well:

1. Have the product owner verify that features are “functionally complete” prior to the peer programming session. They can make sure the workflow is working in a relatively bug-free manner so that the changes that are left are going to be primarily small changes to the design and layout.
2. Use developer-tools to make CSS changes in real time, then copy them into your code once the change you are making looks right. This minimizes the amount of time between code change and feedback (you don’t even have to refresh your browzah).
3. Peer program as soon as a story is functional. That way, your mind is still in the code and you don’t have to re-acclimate yourself. This has the added benefit of avoiding a deliver-reject-restart cycle, which is a bit demoralizing.
4. Take breaks when you need to. Peer programming is tiring, so step away from it every now and then if you are in a marathon session of it. If you get worn out you will also get stupid.
5. Crack some jokes and don’t get all mad. Peer programming can be hard for a certain type of person. You know who you are. You don’t like criticism and every little change is a personal attack. You’re in the wrong business. Okay, seriously, there aren’t many people like that and most of them work in corporate IT environments, but  it’s easy after really long peer programming sessions to start getting frustrated and worried that you’ll never get it right. Just take a deep breath and hang in there. Slog on through, and try to crack a joke or two if you start feeling defensive.

Peer programming throughout a sprint is definitely more effective than using a sprint review as a periodic feedback point. If you can’t get your product owner to review stories during the sprint, just replace the sprint review meeting with a peer programming session and get through as many of the stories as you can. When you run out of time, schedule some more time. Wait – we just said they didn’t have time during the sprint – why can we schedule it now? Because peer programming is something most product owners will really like. They get to see the site change in real time and find lots of value in this. Everybody can find time for the things that matter to them, and once product owners get it they will free up time.

Sprint Reviews without Demos

So, we just kicked sprint reviews to the curb, but should we really abandon them altogether?

Maybe. It’s very easy for demo-less sprint reviews to become meetings with high ceremony and low value. It’s probably better to not have them than to have those types of sprint reviews. I would only hold a sprint review if there are meaningful issues to be discussed, and then I would plan retrospective activities to help work through the issues. Rote sprint reviews are a waste of time. Make them meaningful or toss them.