If you build it they will come, and other lies you’ve been told.

Posted on by

A group of plucky college kids churn away in their dorm room creating the next website   that takes the world by storm. After months of hacking away, the site is unveiled to the world and instantly becomes a runaway success.

A pair of developers spend their evenings around their kitchen table working tirelessly on the next killer app. After weeks of work the app finally emerges from the dim light of the kitchen to become the latest app store hit.

LightBulbWe’ve all seen the movies and read the stories, a group of outsiders create something completely under the radar that when unleashed on the world becomes the next runaway success. It’s sexy, it’s exciting, and it’s inspirational to millions of young entrepreneurs. However, there’s one problem: it rarely happens that way.

Sure there are the exceptions, like the Facebooks and the Angry Birds of the world. But what makes these stories so sensational is not that they’re the norm…it’s that they’re the outliers.

In reality, products that are built inside the vacuum of a dorm room or kitchen often emerge only to a different kind of vacuum: silence. More often than not these products that have been built without customer input tend to miss the mark in meeting, much less exceeding, the market’s needs. They rarely provide that “a-ha” moment or “scratch the itch” the customer never knew they had. Instead, these products are met with a lack of interest or impact, if the customer even looks at them at all. The end result is that the product of all of that work in the vacuum becomes yet another casualty of missing the mark.

Getting customers involved

Most companies test their product with customers during beta phases, but this late in development many critical decisions have already been made. These decisions can make it difficult to correct the issues brought up by customers during the beta process. Rather than taking advantage of the opportunity to learn how their product can better serve the customer’s needs, many teams insist on spending this time trying to sell the customer on why the decision they made without their involvement is actually better.

Other teams take the opposite of approach. They spend endless hours interviewing customers before a single line of code has been written, instead trying to divine the customer’s every want and need. These sessions are incredibly valuable and yield a fountain of user information about the day to day struggles and pain points a customer faces as well as what could make their life better. While this is a great start, unfortunately many of these promising teams then take their new found information away and disappear for the remainder of the development process. By the time they reappear they’re often dismayed to learn that the customer’s initial vision and the reality of actually interacting with the end product are often nothing more than a study in stark contrasts.

Customer involvement throughout the entire life cycle

What’s wrong with these scenarios? In both cases, the team is seeking customer feedback. In both cases the team seems genuinely willing to hear what the customer says. However, in neither case does the team does set themselves up to respond to the customer’s feedback in an efficient way.

In the first case, the team can incorporate customer feedback at the beginning but will never have the opportunity to course correct since the customer doesn’t see the product again until launch. In the latter case, the the entire product has been developed on assumptions of the customer’s needs that were never even validated. The solution is to involve the customer from start to finish. Incorporate the customer in the early visioning of the product, and make the effort to understand their needs. Then, as development begins, continue to seek feedback from the customer throughout the entire process, evolving the product as the customer’s needs evolve in light of realizations about what your product can deliver.

If I’d ask people what they wanted, they would have said a faster horse

This quote, often attributed to Henry Ford, is usually cited as an excuse for not asking customers what they want when building a product. But unfortunately the quote focuses on the wrong question to ask.

Asking what a customer wants will yield less than stellar results…instead ask the customer what they need. What one thing would give them the edge against their competition? If money were no object, what would they do for their business? Spend time with the customer learning how they do business. Learn the pain points that have become so routine and such a daily part of their lives and they don’t even notice them anymore. And most importantly, encourage them to dream and to challenge you on what they want…not what you want them to have.

But we’re disruptive

And I’m very happy for you. However, being disruptive is not an excuse for not talking to customers. Even disruptive ideas benefit from feedback. Don’t flatter yourself to believe that your the first person who has ever thought of disrupting the healthcare/financial/education market. You’re not. Others have come before you and they have failed. Talk to your customers and understand why those others have failed. There’s a reason your customers did not buy from those others, you owe it to yourself…and your product…to understand why.

Take the opportunity

We all want to build great products. We all want to create things our customers want. However, many of us miss an easy opportunity to gain insight into what our customers want by simply involving them in the product development process. Talk to your customers, you’ll be glad that you did.

How to Build the Right Team

Posted on by

Did you know that payroll is usually the biggest expenditure of any software company? If you do, then it should come as no surprise that many companies tout the line ‘people are our greatest asset’. However, it can be scary just how little thought those same companies put into hiring the right people for their teams. Here are some things that we’ve learned over the years which have helped us continue to build a great team.

A-B-R. Always Be Recruiting

With apologies to Glengarry Glen Ross, the number one rule of the game is Always Be Recruiting. Too many times a team will only think about who they would like for an opening just as that position is posted. This is the easiest way to guarantee that you’ll move faster than you meant to on a hiring decision and inevitably settle for a candidate. And, when you’re working on something as important as growing your team, settling is one thing you do not want to do.

So how do you prevent yourself from being forced to make a decision before you’re ready? By always having a pipeline of strong candidates available at any given time. We build this pipeline by constantly having a recruiting presence in our local market by getting involved in networking events, user groups, or by just encouraging our team members to get out and build their own relationships among friends. We’ll regularly troll user groups looking for people talking about the same types of ideas that we value as a team. Or, we’ll post our open positions to LinkedIn and Twitter which allows us to instantly reach out to former colleagues who may be in the market for a change. The goal is to constantly be building a pipeline of great candidates that is ready to draw on whenever a position opens up.

Know Your Gaps (And How to Fill Them)HowToBuildTheRightTeam

At the beginning of each year, we make a list of the skills we have on our team and the skills we need…i.e., our ‘gaps’ for the more business savvy amongst us. The result is a list of skills that we know we need to get better at in the coming year, or that are missing entirely from our team. What’s interesting is that the vast majority of our gaps tend to be very niche skills rather than full-blown positions. For example, rather than ‘DBA’ we may list ‘SQL Server performance tuning’ as a gap. But unless we think our team of less than 6 can support a ‘Senior SQL Server Performance Tuning Specialist’ we’re not likely to be hiring it as a full-time position anytime soon. That leaves us with three options:

  1. Grow those skills in our existing team through training and education.
  2. Temporarily bring those skills in from outside through a consulting engagement.
  3. Find a candidate for an existing position who also happens to bring those skills to the table.

Finding a candidate who already has those skills can be a huge win, arguably even more so than growing them in-house since the incoming candidate presumably has real-world experience putting those skills to the test. But how do you find such a candidate? By looking at those who are already in your pipeline.

Imagine that you have an open Software Developer position. Now imagine that you have two equally skilled candidates applying for that same position. Both have several years of experience with the platform that you’re currently using and both have logged enough hours in your domain to wield the arcane terminology of your industry like a second language. However, one candidate worked to improve the performance of a large SQL Server backed application at his last job by tracking down multiple bottlenecks between the application code and the database. Remembering our skillset gaps from above the choice becomes clear. By hiring a developer who already has those skills not only do we fill an open position, but we also fill one of our gaps with someone who can share her experience with the rest of the team.

Don’t Hire Yourself

Let me be abundantly clear, in a team-oriented field like software development fit trumps all. How someone’s personality fits in with the dynamic of your team, regardless of how amazingly talented they may be, is the single biggest factor as to whether or not they’ll be successful. However, just because you’re hiring for someone that fits in well with your team, doesn’t mean that you want your very own Mini-Me.

One of the biggest results of the rapid evolution of our field is that there are now tons of moving parts to any software project and countless ways to handle each of them. Odds are that you’ve developed some pretty strong opinions about the best way to do each piece and, odds are, you’ll gravitate towards others who share those same opinions. Because, if we’re really honest with ourselves, we tend to believe that our opinions are correct by the virtue of them being our opinions. Hiring someone who shares those opinions can have some great advantages as long as we remember this: those that share our same opinions about techniques and technologies will inevitably share our same blind spots. This is true whether those blind spots are confirmation biases about a given platform, ignorance of emerging alternatives, or just misunderstandings about how an alternative technology works. Don’t perpetuate those same blind spots by hiring them again.

Summary

In a knowledge worker industry there is no single greater advantage that you can give to your team than to infuse them with good people. Why not approach this task with the same rigorous thought and attention to detail that you expect each member of your team to bring to their own tasks?

No deadline. No ship. It’s that simple.

Posted on by

When I was a kid, my big sister and I were addicted to a show called “Out of This World”.  The show revolved around a Evie, a young girl with an alien for an estranged father, who could freeze time simply by pressing her index fingers together.  I don’t have to tell you that this is the type of concept that takes hold in the mind of an 8 year old and never lets go.  I also don’t have to tell you that I spent countless hours in my room pressing my fingers together hoping that ‘maybe this time’ time would freeze for me.

NoDeadlineNoShip

As I’ve gotten older, obviously I’ve realized the fallacy of this idea.  The idea that a race of aliens (the Antareuns, I believe) who are capable of freezing time could ever develop interstellar travel is ludicrous.

You see, interstellar travel would be a huge technological achievement, even for the race of extra-terrestrial swingers that existed in the show.  An achievement so large, in fact, that it could have only been wrought by the constant pressure of deadlines.  The problem, however, is that deadlines and time pressure would be meaningless to a race that could freeze time on a whim.  Why march towards a ship date when you can just freeze time until it’s ready?  What forces the tradeoff between delivery and functionality when you can simply freeze time until all of the functionality is done?  You see, as technologically advanced as the Antareuns were they lacked one crucial piece of knowledge that we learned in software long ago:  if you don’t have a deadline, you’ll never ship.

Without the pressure of a hard deadline features will creep, schedules will slip and a released product yours will never be.  Part of the reasoning behind this comes back to an idea known as Parkinson’s Law.  Parkinson’s Law succinctly states: Work expands so as to fill the time available for its completion.  What this means in a nutshell is that regardless of the true time required for a task, however much time you schedule for the task is how long that task will take.  Do you have a 1 week feature on the schedule for 2 weeks?  Then that feature will take 2 weeks.  How about that 30 minute meeting scheduled for 1 hour?  Congratulations, you just bought yourself a 1 hour meeting.  Like water, any task will invariably expand to fill the time allotted for it.

So what happens when you have a task without a deadline?  Then that task has an infinite amount of time allotted for it, and thus, that task will never be completed.  If you want to ship your product then you have to set a deadline.  No, your product won’t be done at arrival of your deadline.  It won’t have all of the bells and whistles you so desperately believe that your customers need and it won’t have that last 0.999% of polish that it would be unthinkable to release without.  However, guess what: your competitor’s product won’t be done yet either but it’ll already be in the market.  And if their product is all your customers are going to see, then all of the polish in the world won’t save you.