Tony Winn

This morning I attended Creative Mornings Orlando where Craig Ustler talked about his Creative Village development project. For those not familiar Creative Village is hoping create a live, work, play community for the ‘creative class’ (think programers, designers, ect) in a distressed neighborhood. These are my thoughts coming out of todays meeting.

The talk of the creative class is unsettling to me. Classism is bad in general, and its especially bad at creating healthy communities. At the heart of the classism is elitism. We don’t just exclude the poor. We, to the extent we’re able to, distance ourselves from established power too. We complain that bank presidents and Government officials just don’t get it. We get it.

The creative class is not special, and we’re certainly not going to make any positive and meaningful contributions to our communities if we keep thinking that we are. We don’t get it, and we need to acknowledge that. We don’t get interdependence. We don’t get personal honesty and transparency. We don’t know our worth aside from our work. We don’t get that other people have worth aside from their work. We’re broken people and the things we make reflect it. Broken art is the best kind of art, but the artist has to acknowledge it to create something beautiful.

We fail to acknowledge that there is a cost associated with shaping our environments to fit our desires. We fail to acknowledge it because we won’t be the ones paying the cost. We hold up Brooklyn as the model for creating a community of creative people, but we don’t tell the stories of the people that lived there for generations and now have been displaced. I’d recommend checking out the trailer for my Brooklyn to see the other side of the story there.

This is how the story plays out when we start our development work with places instead of people. If people are being dignified and given access to the means of production we don’t have to worry about building buildings. They’ll build them themselves. We’re not primarily interested in developing people in our innercity though. If we’re honest we’ll admit that we don’t want a thriving indigenously-led authentic community in Parramore because we don’t think we’d be welcomed there and that makes us uncomfortable. This is the exact same feeling that the residences of Parramore have about creative village.

This week at work I was scheduled to write a blog post about how we use metrics in our product development cycle. I suggested the post because I felt like we could be using metrics more effectively in our product development, so really it was a feature request disguised as a blog suggestion.

Before I wrote a single line of code I started writing the blog post about the system I wish we had. Writing the blog first helped me focus on how the feature would be used rather than getting caught up on implementation details too early in the process.

Here’s how I think it helped

1. Creates Exciting Features: In a blog post you’ve got to excite the reader with what is so cool about this new feature you’re adding. As a result you’ve got to make your feature pretty awesome.

2. Creates Straight forward Features: The problem that the feature is solving and the solution need to be easily explainable. This keeps the feature scope to only what’s really needed.

3. Creates Complete Features: A blog post has a deadline. We do weekly blog posts and so reguardless of what happens the blog post needs to get published. This is a really great way to eliminate feature creep.

Conclusion

In the end you get features that are straight forward complete and exciting. At the same time you’re marketing your application. How often have you got to the end of a feature and didn’t have time to write up a post on it?

I highly recommend giving it a try for your next feature.

This weekend the third young man this year from my neighborhood (Holden Heights) was killed. When I moved into the neighborhood, two and half years ago, I knew what I was getting into. I had been trying to move into Holden Heights for the previous 2 years. I read up on the history. I followed the news. I looked up statistics. I knew more about this neighborhood than any I’d ever lived in. I knew it would take years for an outsider like me to gain trust.

What I didn’t know was how easy it would be for me to be in the neighborhood without living in it. I shop outside the neighborhood. I work outside the neighborhood. Most of my closest friends live outside the neighborhood. I go to church outside the neighborhood. If things got bad enough I could easily leave the neighborhood.

These things (among others) separate me from my neighbors. It seasons my empathy. It rightly brings up questions of my trustworthiness. It overshadows any idea I might have about what ought to be done in the neighborhood.

While it took me two years of planning and trying to move into the neighborhood, it’s going to taking me a lot longer to start living in the neighborhood.

Over the past two months I’ve been working on creating and expanding a particular feature set at work. After the first month we released the first part of the feature. We sent the VP of sales to a conference full of potential users for the feature and even got a few articles written up about it. To date not a single person has used the feature. As a startup it’s hard to make good decisions about product direction, it’s even more difficult knowing what levers to pull to engage your users with a new feature. Here’s 3 tips on how to release and promote successful features.

1. Become your own customer. This can be very hard to accomplish if your customers are in a fairly inaccessible industry, ie maybe they build submarines. If you’re in the position to build your own submarine then by all means build one. It will be a super valuable exercise for your business. Companies like Github are in an awesome position, their product is also their tool. They’re software developers that are building software for software developers. It’s an ideal situation when you can build features for yourself because you really are your own customer at that point. Lets say for example, that your product is an advertising platform. It would be in your best interest to encourage your employees to become your customers. “But my employees don’t have anything to advertise!” you might object. Ask them, encourage them to come up with their own side businesses to advertise for. You’ll suddenly have customers with power and motivation to improve your product in ways you wouldn’t have known to do otherwise. At the very lease the employee that made the feature will want to use it.

2. Tell a story in a place and way that your customers will want to listen to it. Find out where your customers spend their time. Obviously if you are your own customer you’ll know already. If you’re unable to reasonably do this (court software for example, it’s hard to set up your own little justice department), talk with your customer get to know them. Find out what they value. Find who they respect. If all of your customers are hacker news junkies you need to be too. You’ve got to know what stories make it there. You’ve got to build trust among that community of people. Now you can start thinking about sharing your story. Notice I didn’t say announce your cool new feature that everyone should use. There are a handful of products in the world right now that people care enough about to read about new features. If you aren’t Google Facebook or Apple, people probably won’t care. But people care about stories. Maybe my VP of sales could write a blog post about the conference with lots of pictures. The feature is part of that story, but it’s not what the story is about. Maybe I could write about the technology used to create the feature. What worked, what didn’t. Really though the one place you can guarantee to reach your customers is on your own site. Does your own site convey information about the new feature. Does your site seem excited about it? Displaying information in a positive manner is just the bottom 10% of what you need to do. Again people don’t care about features they care about stories, short stories. Cast your customer in the most believable role of their lives. The hero needs to be your new feature, but it needs to be a realistic relatable hero. Do this before you implement anything. If the customer isn’t believable or the hero seems like a wimp, it’s time to rethink the feature.

3. Q: How many weak features does it take to equal one kick ass feature. A: Zero. Simplicity is your most powerful feature. Do a few things awesome. Having a mixed bag of features is like trying to watch a Phillip Seymour Hopkins film co-starring Kenu Reeves. It only takes one confusing or unwanted feature for your customers to zone you out.

Tonight my dev team goes to production for the first time since I joined. Here are a few lessions I learned along the way.

1. Get everyone in the loop that needs to be. I made the mistake of only thinking about my own responsibilites for the project instead of being proactive about informing others about what would be needed. The role is really two parts programmer one parts project manager. I should have realized this sooner and got more people involved. Maybe a project status email would be helpful to send out, or even better daily stand ups.

2. Think two plays ahead. We’ve got qa person who most of the time has availability untill we push our working code to qa and give him the green light. I should have gotten him more involved at the start of things. He’s a smart guy and would like to get stuff up and running with Cucumber I should have seen that posibility and given him what he needed to make this happen.

3. Stop the crazy cycle, write a test I found myself on a few occasions during the iteration saving and checking and saving and checking till I just wasn’t having fun anymore. I even had a bad attitude when I got home. I need to recogize when I’m doing this earlier and force myself to just write the freaking failing test. It’s a good investment for today, it’s a great investment for tomorrow.

4. Red, Green, what? At some point in the project I got out of the TDD mindset and was just making chanages and running tests. My code shows that it hasn’t been refactored and I know I’m making more work for myself and others later.

5. Ask for feedback early and often. After the project was over I took the time to fess up to mistakes that I made durring the iteration and asked if there was other stuff I could have done better. This was a really good experience. While I didn’t get a ton of feedback, the team reacted positively to it and I think it will help people feel comfortable giving me feedback in the future. I think I potentaly missed out on some helpful feedback earlier in the project by not asking sooner.