DeveloperTown

Last month, I was sitting in my first DT design session when I heard something that’s been stuck in my head all day. We were partway through our Ideation session, where we discuss any and all possible future paths that come to mind for a particular project, when Michael Cloran said (to paraphrase): You have to diverge before you can converge. At the time, he meant that we needed to discuss possible long-term directions the app (or suite of apps) could take before returning to the immediate future.

For some reason, this concept resonated with me to my core.

My Personal Re-Design

On a personal level, I’d been planning on getting my PhD in Molecular Biology for as long as I could remember. My summer internship at CIK (home of BizProps and Tri-Auto) changed everything. I spent my next year diverging: taking classes in Entrepreneurship, attending business conferences and Venture Club meetings, and thinking about what I really wanted to do with my life.

I met Michael Cloran at the IU Kelley School Annual Business Conference, and, a month later, I visited DeveloperTown and was sold on the company, the vision, and the people.  It reminded me of my first visit to Rose-Hulman four years ago; a school that hadn’t been on my radar instantly became my #1 choice because it just felt right. Being at DT just felt right because DT isn’t just a job. DT is a lifestyle, a family, and a place to grow. It took really taking a step back and examining who I was and what I wanted to converge on as the right choice for at least my next few years.

DeveloperTown 2.0

DeveloperTown also exemplifies this concept in more than just the Design Process. This past January, DeveloperTown 2.0 was launched, primarily as an internal program to signal that DT would be undergoing major self-improvements. Everyone at DT had the chance to contribute to meaningful discussions on what they wanted to change at DT. From culture to clients and everything in between, townies were taking ownership of the company. Some of the amazing results of this endeavor included Hack ‘Em Ups, a blog overhaul, and even the hiring of almost two dozen new employees over the span of six months.

Because we decided to diverge and rebuild, DT has grown in size and strength.  More than ever before, we are a technical co-founder that will help dozens of startups launch their product this year. But, more than that, we are all part of a company that we can be proud to be a part of. As Michael Coffey likes to say, “Our number one customer is our employees,” and it shows.

Since starting here, I’ve done everything from helping refine the sales process to writing my first blog post to getting demolished at ping pong on a regular basis (as Pong Tracker clearly shows). For the first time in a long time, I don’t have a plan for the next two, five, and ten years. I don’t know where I’ll be living and working three years from now. All I know is that, at least for now, DeveloperTown is my home, and I love it here. I’ve converged on where I want to be, and it feels amazing.

My House:

When I decided on Marketing as a major I had the thinking that Marketing was this thing that was a post product launch activity and then eventually you just tinkered and refined things as the product matured.  I also had the mindset that marketing was either a job in communications, sales, research or analytics and that would be one of my choices upon graduation.

Here are a few things I have learned since graduating from college about marketing:

-  It is something that starts from Day 1 of a company
-  Marketing is understanding your customer and building a great product/service specifically for them
-  The most important part of marketing is the Product, not the 3 other P’s (although you must also do them well to succeed)
-  Everything a company does is marketing because everything you do is being perceived and interpreted by the world (especially in today’s social media world)
-  If you don’t define who you are and your messaging, someone else will.  And usually that ends up in a place that has you scrambeling
-  People don’t care much about all the whiz bang gadgetry you have.  What they do want is to know how all of that benefits them.
-  You have to connect with people on a real level.  People love and identify with authenticity.

And probably the most important thing I have learned is this:
-  Tell people who you really are and what you provide.  The more you build yourself up and don’t meet those expectations in the customers mind, the more effort you will have to put in to repair your relationship with the customer.  Don’t mislead people with the marketing machine and hype.  Tell it like it is.  

If You Need a User Guide You Have Already Screwed Up
This is a pretty commonly held belief among designers, and it rings true because there is some truth to it. I would amend this platitude to read as follows:

If you need a user guide BECAUSE YOUR SOFTWARE IS HARD TO USE, you have already screwed up

I have resisted multiple requests to provide my TroopTrack users a user guide over the last four years for exactly this reason. When my users asked questions, it was mostly because parts of TroopTrack were poorly designed. So, most of the time, instead of writing a user guide, I would simply use their input to guide a re-design of the feature in question. This was educational for them and for me, and it was absolutely critical in the learning-process as a product owner for me. This back and forth design cycle between the users and myself helped me to understand their problems well enough to build a product that is, in my opinion, the best scouting software on the planet.

There are Other Reasons For Needing a User Guide
I frequently call trial users and ask them how things are going and if I can help them get started. Perhaps this was just a freak coincidence, but two customers in a row told me the exact same thing:

Your software looks nice but we went with TroopWebHost.com because they have a user guide.

These interactions taught me that there are other reasons for having a user guide that have nothing to do with software design.

• Reason #1: A user guide is frequently an important item on the evaluator’s checklist, whether your software needs one or not. Not having a user guide often means they won’t even consider your product.
• Reason #2: Purchasers of scout software have to convince a committee that my product is the right one and the lack of a user guide makes that a more difficult task.
• Reason #3: A user guide is often perused by potential buyers as a way of seeing what your software is able to do for them.
• Reason #4: No matter how well designed your software is, some users prefer learning through demonstration over learning through experimentation. Those users need a guide, or a video, or something.

Maybe You Should Just Roll Your Own User Guide Infrastructure
There are solutions out there building wikis and user guides etc. Some of them are free and many of them are not. I’ve tried lots of different things over the years, including:

• RedMine – too painful and ugly
• ZenDesk forums – forums aren’t user guides and users leave my site
• Atlassian Confluence – lovely but expensive
• Comatose – the gem is dead, unmaintained, and stale
• Refinery CMS – I don’t want a separate admin tool for help pages (otherwise I lourve Refinery CMS)
• ActiveAdmin + Awesome Nested Set + CK Editor – User guide bits and bites delivered in less than an hour!

I already had active admin, and it’s super easy to add CK editor to active admin forms, so all I had to do was create a simple model with a title, body, and the ability to nest pages. With Rails, I was able to do that in about a half an hour, but I rounded up to an hour cuz I don’t want to seem vain.

What About the Content? Let the questions be your guide
I use ZenDesk for my support tickets, and about half of them are questions. I’ve fallen into a pattern with these support tickets that I think is very lean. Here’s an example:

Hi John,
Based on your question, I put together a new page in the User Guide this morning to show how to edit user info such as birth date and phone number. Here’s a link:

https://trooptrack.com/help_pages?page=53

Please check that out and let me know if it doesn’t work.
Thanks!
Dave Christiansen,
Owner, TroopTrack.com

I like this approach because it doesn’t duplicate effort and I know the content is needed. The problem with this is one I experienced when I was trying to use ZenDesk forums in the same way – it’s easy to end up with an unstructured mess unless you give the user guide a structural smackdown as you go.

I started out with a skeleton that mimics the structure of my application. This is a pretty common approach and let’s face it, there’s no huge need to be innovative here. A user guide that is structured like the application is pretty intuitive. It might be more artsy to write it like a novel, but … (Oh, hang on, I find myself tempted to try that).

A Page a Day Keeps the Wrackspurts Away

I went on a bender one weekend and wrote about ten pages in a day. That drained me of all energy for writing for about a week, and I suspect it is not a sustainable way to do it. I’ve since switched to a page-per-day approach. Sometimes I will write more if I have user questions to answer, but if I don’t I stop myself at one. At one page a day I will have a fairly comprehensive user guide by the end of June.

Don’t Over-Invest, Mis-Invest, or Pre-Invest
A few years ago I was part of a project that hired a technical writer to write a comprehensive user guide. We paid her thousands of dollars and she did a very nice job, but I’m not sure the user guide was ever really put to much use. We still got lots of questions that weren’t covered by the user guide, and our customers started asking for the ability to customize the user guide for their particular policies. We had over-invested, mis-invested, and pre-invested in the user guide. All of these were mistakes.

The meaning of over-investing is probably obvious. Spending more on a user guide than is needed. Mis-investing and pre-investing may not be so obvious.

Mis-investing is spending your user guide investment on the wrong things. Our tech writer set out to cover every single feature of our software, from logging in to logging out. There were lots and lots of pages that I reviewed that merely re-stated what was obvious from the user interface. This was a mis-investment.

Pre-investing is spending your user guide investment BEFORE your product is stable enough to be documented inexpensively OR before you really know what users are confused about. Pre-investing and mis-investing usually go hand-in-hand because you are GUESSING what documentation is needed and you are going to be wrong some large percentage of the time.

User Guides Can Be Good Investments if You’re Careful
Needing a user guide doesn’t necessarily mean you screwed up. But you should be certain that investing time and money into a user guide is the right thing to do. It is very often the case that you should be fixing your crappy software instead. That was definitely the case with TroopTrack for several years, and even now I don’t try to “user guide” my way around a feature that is poorly designed. I just fix the feature.

Also, don’t spend money on user guide pages you don’t need. Let users show you the way so that you don’t mis-invest. Only add pages you imagined up to meet a marketing or structural need.

If you’re curious, you can check out the user guide infrastructure I cooked up for TroopTrack (in less than an hour!) here: https://trooptrack.com/help_pages

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.

We’re making significant strides over here to improve our design process. And by design, we mean a lot of things: building a startup vision, creating the user interfaces, and presenting a beautiful look and feel for our clients.

My current work is primarily on a client project called TPG Marine Harbor Management System. Yes, long name, but the project boils down to helping barge servicers track their fleets and automate billing. Crazy stuff. I joined the project as the second developer, but I’ve since taken responsibility as the designer.

The way we’re doing design on TPG is this way: we figure out what problems we want to solve in the next several weeks, and we start designing solutions today. The challenge I’ve faced is knowing when I’ve completed a design task. Finishing design isn’t as clear-cut as completing implementation of a feature. Should I mock up every detail for the developer? Should I code all of the html/css and hand that over to the developer? And most importantly, am I done yet!?

I’ve come to realize that the most important aspect of design is CONFIDENCE. The ultimate question in my head is, am I confident in my approach to a solution? When confidence becomes the key to finishing a design, the less important details become, well, less important. No longer do I feel the need to write tons of html, css, and javascript to feel “done.” I write as much as it takes to feel confident. The design may appear half-baked, sometimes sloppy, and maybe even ugly. But that’s ok…because I’m not trying to perfect it yet, I’m just trying to convince myself that my approach will work.

Because we live in a world of scarce resources, we need to figure out what get’s us to completion the most efficiently. Here are some ways in which I’ve tackled finding confidence:

Wireframing

Wireframing seems to work well when an app is being built from scratch. It helps answer questions like, what content needs to exist? What actions can be taken? Who are the users? I haven’t used wireframing much since my project is far beyond the initial design phase.

Sketching

Sketching helps get design insights tangible quickly. Skteching can help you visualize a solution without committing much time. I’ve found that the ease of finding confidence or the lack thereof from a sketch depends on my level of experience with the project I’m on. The more experience I have, the better my intuition and thus  the more easily I can vet ideas in the sketching phase.

HTML / CSS / Javascript

Since my project has an existing codebase, I spend most of my design time working with these three tools. Using git, I checkout a design branch for each design task and start messing around, searching for what interface and interactions (clicking, entering data, etc.) give me confidence. For my last design task, I abruptly stopped working on my design and concluded I had confidence, long before the interface was polished and the interactions complete.  But that was OK, because I knew I could perfect everything after design is finished.

(For all Rails/Git folks out there, an extra tip: I will clone a second copy of my repository so that I can run two versions of my app, one for development and one for design. That way, I can see my design work in action in a browser window while implementing the design.)

The goal here of this design process is to think critically about designing solutions before implementing a solution. But it’s also to be lightweight as possible. Good developers on small teams don’t need to know every pixel of an interface. They need to know what the solution is. The deliverable from these design tasks is often nothing more than a series of implementation tasks for developers, a half-baked demo, and maybe some code to reference.

I would love to hear your thoughts on approaches to design. I’m sure the approaches will vary, given the needs of different clients, projects, and teams.

Last week, David Heinemeier Hansson (creator of Ruby on Rails and partner at 37Signals) attacked a popular version of test-driven development: the TSA-style. The overarching characteristic of TSA-style test writing is failing to ask why a needless security check test warrants a breath of life in an airport app’s codebase. His main point is that tests aren’t free: they have a long-term maintenance cost like every other feature. And if tests aren’t free, then you better pay close attention to the tests you choose to write, because they’re costly.

At the heart of his blog post is a scorn for hard-lined test-driven development. And for the most part, I couldn’t agree more with him. But the part missing from his essay, and the part of TDD that most resonates with me, is that TDD drives good coding patterns.

When the going gets complicated, the complicated gets…tested

DHH’s last point was: “Don’t force yourself to test-first every controller, model, and view (my ratio is typically 20% test-first, 80% test-after).”

The idea of writing tests first, coding second comes from the idea that “if you can’t test it, then it’s not good code.” While this may not always hold true, I’ve found that this approach guides me as I write code.

When a feature gets complicated, it helps to write out what you expect to happen before firing away on all cylinders to implement it. And, in the world of startup-land where we don’t have bountiful time to write tons of Cucumber and Selenium tests, this is called writing a spec of unit tests.

When it comes to features with complicated requirements in Rails models, I almost always test first. This is not to say that those tests won’t change as I write code. In fact, once I have my basic tests written, I start implementing to get a feeling if the pattern proposed by my tests work or not. I spend time refactoring both my tests and code until I’m satisfied. This approach helps me break my models down into healthy, maintainable parts.

Even in writing javascript, the “test first, code second” paradigm plays a role. While I don’t write unit tests for javascript apps, I do try to write my code in such a way that it could be unit tested. That means delegating responsibility through the javascript app to ensure I can “isolate” expected behaviors (i.e. avoiding “spaghetti” javascript).

Where to draw the line

I think DHH nailed the hammer on the head: it’s easy to waste our time writing unimportant tests while leaving less time to test the critical, risky parts of our app. But in the process of doing so, he tried to refute what, to me, seems to be one of the most rational reasons for test-driven development: driving good programming patterns. I would encourage any new programmer to keep this in mind when valuing testing.