This is part of my ongoing posts on Startup Advice.

The world has changed much since I started my first company in 1999.  As organizations we have become more open and I believe this is great for businesses and their customers.  In the first 4 years of running BuildOnline we were an “Outside In” organization.

We spent time out in the marketplace talking with customers, looking at their solutions, comparing ourselves with our competition and then squirreling ourselves away in our offices designing our next set of features.  The Outside In organization had a one-way flow.  Our sales guys were on the front line and heard what they needed to win deals.  They communicated this to product management who looked at all of the internal requirements we had generated (e.g. some came from our customer service, some were to improve performance / scalability from tech ops, some were bug fixes, etc.) and product management worked with me to decide what to build & when.

We then set out to build these features as quickly as we could.  When we had a beta version completed our marcomms team (marketing communications) would start drafting messages to release in PR statements, our customer support teams would get ready for inbound calls, our product marketing teams readied themselves with updated PowerPoint slides to arm the sales teams with and we all geared up for “launch.”  This process seems so archaic now but I think that’s how the software industry mostly operated for 20+ years.

What changed for us was Tim Barker arrived.  There are rare individuals in the world who see the future and are strong enough personalities to insist that we need change.  Tim started to change our processes.  He decided that our largest customers would be involved in the setting of our priority lists (we did some of this internally in the early years but we saw it mostly as a sales process).  He published our first wiki where the whole list of potential features were outlined.  He made customer-to-customer dialog possible and visible.  And he gave them all early access to our prototypes for reaction.

I know that this all seems obvious now with the movements started by Steven Blank (Four Steps of Epiphany) with the whole Customer Development processes / Lean Startup movements also popularized by people like Eric Ries.  Back then it seemed foreign.  Tim encouraged us to set up a blog and start talking openly about what we were doing as a company and inviting comments.  This was 2006 and we were now working on our second company.  But it seemed strange to me that we would openly talk about stuff rather than waiting for a big announcement to the press.  But I had been reading Munjal Shah’s blog about his experiences at Riya (later renamed Like.com) and this openess had an appeal to me.

So I started thinking about the “Inside Out” organization.  This is the company that lets outsiders have a glimpse of what is going on in the sausage factory.  Being transparent about our workload, our struggles, our fund raising, whatever.  Letting our customers and the market know that we were a real organization with real people rather than a pre-packaged, pre-processed marketing machine.  Customers, press and the market responded positively.  ‘

Here are some steps in the Inside Out organization.

1. Understanding Customer Requirements

This is the part of the Inside Out organization that I think is best understood yet I’ve observed some companies who have gone the extra mile.  I spent time with the folks (Klaus Schauser and Brian Danahoo) at AppFolio before they ever launched their products.  The first application they ever launched was in the property management space.  They did the obvious things like going and talking to property managers to see how they used existing products like Yardi or Excel and what was missing to make their jobs better.  They proposed feature sets that they would plan to build and stack ranked how important these customers thought they would be.  They attended property management association meetings in Oregon outside of the technology echo chamber of California to get a sense for people’s daily problems.

But they went one step further.  They recorded many of their sessions on video.  They taped people using existing products.  They truly wanted their entire organization to understand what we in tech too casually throw around, “A day in the life of …”  We often think we know it.  They recorded it.  I was impressed with their desire to truly understand the customer.

Another great example is Bill Barhydt of m-Via.  m-Via does financial remittances using mobile phones for people from the US to Mexico.  This is a huge industry dominated by Western Union with a very limited service to its users.  Annually it is estimated that $25 billion in transferred each year (another $20 billion crosses the border).  For an industry that takes 10% it means about $2.5 billion in fees / year.  It would have been very easy for Bill to do a desk-based research project on how to improve the process.

But Bill actually went himself to remote parts of Mexico to understand the “cash out” component of remittance.  He found that families were afraid of taking out large sums of money for fear of their personal safety.  He still flies down to LA frequently and travels to East LA to understand the “cash in” component.  Who in the family sends cash, how much, how frequently, etc.  Bill knows a tremendous amount about US/Mexican cash transfers.  Yet he still personally travels in his customers’ neighborhoods in search of deeper customer insights.  It is inspiring to hear him talk about this.

2. Watching User Interactions

– One of the biggest problems in technology is that systems are designed by people who are technical by definition.  I used to always tell my development team, “you need to design a product that my dad could use.  He’s a smart guy.  He’s a doctor.  But he didn’t grow up with technology.  He never pays attention to all of the feature creep in products and in many ways the more features the less he is able to use the product. My Dad uses email – he still doesn’t understand the ‘forward’ button.”

So my mantra was (and is), “Design for the novice, configure for the expert.”  What I mean is that products should be as simple as possible by default.  Advanced users will always figure out how to configure the product to layer in all of the bells-and-whistles that we build into the product.

But even with this in mind we churned out products that were too complex or didn’t meet customer expectations.  My second company, Koral, was designed to be as simple as possible.  We wanted to be the YouTube of document sharing so rather than requiring users to download documents we converted them into Flash so you could scroll through them online (I know this is common today, it wasn’t when we launched).

Then I met a company that went one step further.  It was Salesforce.com.  Where we designed what we perceived to be a simple product they turned the customer development process it into a science.  After they acquired my company they had us show our product to groups of non users in a room with two-way mirrors and with cameras rolling.  They incentivized people (as simple as a Starbucks gift card) to come in off of the street and use our product.  They were given only the most basic instructions on what our product did and they were asked to complete tasks.  I swear my team all lost 30% of their hair that week.  Nobody could believe “how these morons couldn’t figure out how to do A, B C”, “Can’t they see that freakin’ upload button there!”

It was humbling.  Even while designing what we perceived to be a simple product we learned many lessons from these sessions.  Many startups today don’t do these kinds of sessions.  You don’t even need to be too scientific about it.  Trust me you would gain by watching random groups of people using your products and taping the sessions so more people in your company can learn.  I am certain the results will shock you.  And you’ll design a better product as a result.

3. Getting Customers Involved in Product Priorities

Around the time that Salesforce.com acquired my company we also acquired a company called CrispyNews.  They had decided to take a Digg style approach to product development.  The product was rebuilt and launched as Salesforce Ideas (and if memory serves it was also called the Ideas Exchange).  We used the product internally but also sold it to customers such as Dell and Starbucks to power their customer feedback forums.  The idea was to create a systematized way of letting your users and customers have a say in what your future product features should be.  It was “wisdom of the crowds” meets “product development.”  We got great ideas from our customers and if some features got tons of votes we knew that many people (or at least vocal people!) cared about the feature set.

I know that their are independent software companies now focused on this like UserVoice and Get Satisfaction.  Why on Earth should we as small startup companies think that we have a monopoly on all the best ideas.  Products like these basically help you crowd-source your customer service input and product development pipeline.

4. Openness in Blogging

The most obvious and visible part of the Inside Out organization is blogging.  I know that many management teams think blogging is a time suck and a distraction.  But I believe that it creates an authentic relationship with your community.  I mentioned previously the cult status that people like Munjal Shah built at Like.com.  My personal recommendation is that your startup blog ought to cover not just startup stories but should also have a voice that speaks to your customer community.

I think a company that did an exemplary job with this was Mint.com.  Aaron Patzer and his team would blog about personal financial management as you can see from this link.  Many people at a young startup are trying to manage their finances like the rest of their user base.  I remember in the early days of Mint when I first played around with the product.  I (like everybody else it turns out) was blown away by how awesome their UI was (especially in comparison to how crappy and complex Quicken had become).  But I was also impressed that their blog really spoke to issues that their users would be facing in managing their money.  I think it has become too conventional for startup CEO’s to blog about life in a startup.  For me it’s more interesting to speak to their user community’s issues.  It is important not to just speak to the echo chamber and impress our friends.

My favorite line about using blogging for PR I heard from Brian Solis who said, “PR doesn’t stand for press release, it stands for public relations.”  When you think about your blog, think about which members of the public you most need relations with.

5. Technologists in the Field

I think the final part of the Inside Out organization is sorely lacking in most companies.  I see many CEO’s, product managers and marketing types out in the field talking with customers and users.  I rarely see the tech team do this.  They’re “too busy getting the next sprint out the door” to spend time in the field.

The whole point of Agile Development is to produce shorter, sharper pieces of code completed more quickly where you can get feedback from customers.  Why wouldn’t we start with our technology teams actually living “a day in the life” of their customers to understand their working environments and needs.

It is not good enough to have the product management team do this.  Tech teams – start a revolution!  Don’t allow this to happen to you.  I know that you chose a career that matches your personality and if you loved schmoozing customers you would have gone into sales (where they get paid sales commissions!) but it is so important to see what your customers do in their daily lives.  Under the old construction adage of “measure twice, cut once” I know you’d produce better code the first time if you knew your customer.

One last quick story to make my point.  I had a very earnest, hard-working and intelligent technology team lead for a project we had internally at BuildOnline.  We were building to-do lists for large-scale engineering and construction projects to support our document management and workflow.  Customers had requested that we build out a more robust solution than our current product had.   Our team lead build a very elegant piece of code for inputting tasks, assigning them, tracking them and reporting on past-due work tasks. He build a wonderful reporting systems around this product.  He took input from product management on what to build but in the daily coding he had to make many decisions on his own.

Mr. Team Lead had never spent time with customers.  I was one of the early testers of the product before it was ready for even a beta.  I instantly knew what was wrong with the product and I was surprised it hadn’t occurred to him.  I had been to enough customer meetings to know that much of what happens in engineering and construction comes from team meetings that you have across many different companies including an architect, engineer, contractor, specialist sub-contracts and the client.  When they leave the meeting they all have 30 tasks.  Mr. Team Lead had build a system where you could only enter one task at a time.  You had to iterate through his entire process before you could enter the second item.

I  didn’t  understand why the UI metaphor didn’t look more like a spreadsheet, which is how many people do tasks.  I’m certain if this team lead had spent more time with customers he would have had a better sense when he was coding. I know you could tell me this was an error in product management or with our whole process and I couldn’t argue.

But I know enough to know that daily decisions / trade-offs are made by technology coders who have never spent a day with their customers. If you’re a startup – fix this.