Productivity by delegation vs. productivity by outsourcing
Teamwork's Q&A's new site
In Open Lab we just adopted a StackExchange instance as support for Q&A’s for our Teamwork product (here), and another one for generic jQuery support (here). Now, the speed with which you put up one of the highest quality services available on the web is such that it ridicules any attempt to build such a service in-house – a mistake that we actually pursued. This has led me to the following thoughts.
Many developers and managers live in a omnipotence dream. The apparent power of a Turing-complete tool, that in principle can perform any kind of computation, feeds the illusion that having developers in-house means that any software task can be solved by simply developing the application from scratch. If this seems obviously false to you, just take a look around and you’ll find more examples that you’d ever imagine.
So, we need a support forum for our product? Let’s just develop one. We need a bug tracking system? Let’s just develop one. We need to build a web site with database? Lets develop it internally.
Taking the opposite attitude, that is, developing from scratch only what is strictly related to your core business, can be a way to becoming more productive. I’ll call this the software delegation principle.
Ok, assuming this principle looks easy enough; but… there are several mistakes that can be taken in sweeping generalizations of the principle above. The worst one is confusing delegation of secondary services with outsourcing the core productivity of your company. There is a semantic difference between “delegating” and “outsourcing”, and it is connected to where you put your company’s worth.
If you put it in designers, developers and their skills, you can delegate everything but their activity, you will have to struggle to keep their focus on our main development, without making them develop say a support forum when it has nothing to do with their core issues.
If you are a software house, renting a coder is probably a bad idea – see Jeff Atwood’s Can You Really Rent a Coder? . For similar reasons, though many developers and bloggers don’t get it, it is just as well a bad idea to rent a designer. Your people’s skills are the core of your value. Like, our core competencies are development, design and marketing our web applications. Anything that distracts us from our goal, should be removed if possible.
Another in some sense opposite mistake is delegating problem solving which touches your core competencies: like using tools that give you simplistic solutions that hide you the real complexities involved and that will lead you to great troubles when going in production. A classical example is like trying to set up a web site using visual tools, without understanding HTML, JavaScript, and eventually the server-side part that goes with that: maintenance, cross browser compatibility etc. will soon become a nightmare. But delegating non core issues will actually help you going in-depth about your core issues. This is the mistake of outsourcing the core productivity of your company.
If you are a traditional custom-development based software house, what I am saying here applies in a different interpretation, simply because the value of the company is in the customers, not in production (in the case of a software house, this means the developers). Quality is concentrated in making deals with the managers, not in providing good solutions. That is why often such companies really outsource everything but marketing.(I personally don’t like much such business model, but that is another matter).
Made the necessary distinctions, if you overcome the temptation to build everything in-house, here are some examples of services that you can delegate if you are developing online services:
Development:
- writing code -> get the best IDEs, working stations, monitors, keyboards, that money can buy (see CodingHorror for many advices)
- integrating third-party technologies in your software: -> rely on available APIs
- designing mock ups ->use Balsamiq Mockups
Testing and support:
- testing your application – use http://www.usertesting.com or similar services
- collect feedback from your users – use an online service like UserVoice or GetSatisfaction
- support questions and FAQ – use StackExchange
Marketing:
- statistics of your site – use Google’s analytics
- following marketing progress – use StartupTodo
These are just some examples that I am using or exploring.
Using the best tools for development, like using the best IDEs (see The Joel Test: 12 Steps to Better Code), goes in the same direction: you delegate syntactic work to your development environment, and you focus on solving the business model problems and, most importantly, on usability.
Productivity by delegation can also be a great source of new products and services ideas; we in Open Lab are just now developing two new products exactly for this end, one for delegating collection errors and user feedback online (BugsVoice), the other for making your web sites dynamic without using a CMS (Patapage). Time will show whether I’m right…
Get visitors to read and remember your home page – applications
This is the second part of the “Get visitors to read and remember your home page” theme, the first is here. These marketing posts are put into context here.
Now that we have the design principles perfectly clear in mind, let’s apply them to Open Lab’s two new online service home pages, Patapage and BugsVoice (public betas will soon be available).
Patapage
So the first version of the Patapage web site home, after brainstorming, was this one:
Now what is basically missing is any reason for the visitor to get interested in the service: the pitch is not good because it refers to itself, it does not talk to the user. So the version got after reading “Made to Stick” is this one:
The pitch is six words, and talks directly of benefits, not just of features. Furthermore, a mysterious link to a short story has been added: the story begins like this
To read the rest, you’ll need to access Patapage’s beta 
Actually, the page we have now is even nicer:
So lets fill the scorecard for the obtained home page:
Not bad.
BugsVoice
So this was the page we first got to after brainstorming:
The pitch is invisible and badly worded.
After revision:
The pitch here is just 4 words! So lets fill the scorecard for the obtained home page:
Now… its your turn.
P.S. We finally changed “turn bugs in opportunities” to “turn bugs into opportunities”, after discussions and enquiries: though it doesn’t sound as nice, it is semantically correct.
Get visitors to read and remember your home page – the principles
This blog post is in two parts, this is the first, the second is here. These marketing posts are put into context here. The process here described has also become a step-by-step project on startuptodo.com.
The day you realize that nobody is interested in reading your product or service homepage because you love it, may be a bit depressing, but may also be the start of a re-design that will lead to more returning visitors. Nobody is going to link, talk, or blog about your product without a good reason to do so. There must be something surprisingly interesting, beautiful, disruptive, horrible, rarely thought of about your home page contents to get people to look at it.
Here I will consider some redesign principles that you may use once you got this “satori”.
So, you understood that your web site needs to convince people: you need a home page that will capture visitor’s attention. Taking the user’s perspective is non trivial, say Dan & Chip Heath, because you are under the “Curse of Knowledge”: it is very hard for you and your team to look at your product from the perspective of someone who knows nothing about it, if you don’t dedicate some time to this. This project is heavily inspired by the principles which can be found in the book Made to Stick by Dan & Chip Heath. The aims of this blog post can be summarized as:
(1) get visitors to read your home page
(2) get visitors to remember your home page
Home page effectiveness analysis
As an example, consider this analysis done on the startuptodo.com home page:
The crucial part of the home page is the pitch or lead, in this case “be successful faster”.
The transparent 1,2,3 are a likely order of attention of the first time visitor: she will first read the lead, then the text below, then eventually go more in detail. In a following step we’ll get back to this structure.
Now focus on another part of the home page:
If you can talk about your product / service features using a story, instead of a set of features, you will be much more effective: people tend to remember stories.
Let’s finally focus on a third part of the page, where the site is asserting its credibility:
By Sinatra effect it is meant that a single great testimonial can raise your credibility considerably (“If I can make it there I’ll make it anywhere…”). This example can be summarized using a scorecard:
The pitch and page scan flow
There is a sort of “page scan order” assumed in designing such pages:
The 1,2,3 numbers in the first screenshot of the site above are a sort of reading order, which you should follow in writing contents. The web site gives different levels of information to the visitor, trying to lead her to the evaluation part.
A perfect sample application of “the pitch” principle and of the page scan order is on the UserVoice site:
Notice that the pitch “Your customers have great ideas. Are you ready to listen?” talks about advantages for the users, not directly about features of the service. Below one gets more information, in two further levels. The pitch is even inserted in the service name!
Now go and (re)design your home page
Some steps that you may follow in designing your own home pages.
Describe your product / service
Describe your product / service and its advantages, the problems it solves, the pain it takes away, in short sentences, using a simple language.
It is often done in a group “brainstorming” session.
Find the pitch
This step will be crucial for making visitors actually read your home page, together with the following step “Break a pattern”. This is the hardest part, probably best done in isolation by the most “creative” writer of the group. You have to find the pitch searching in the second and third level descriptions found in the first step. It has to be a short sentence that presents the product advantages to its users. What it is often used as pitch is a sentence which summarizes the descriptive sentences found in the previous step. Mistake! What you should find as pitch is what the user will gain from your system, not a resume of what the system does. It is a subtle but essential difference.
Write a story about some humans using it
Find a storyboard for a video, or write a short story, with characters, people, talking about your product / service. This is the step which will solve point (2), making visitors remember your home page.
Break a pattern!
Something in your home page must break a pattern. Never do the mistake of cloning a successful site layout and that’s it. People just don’t look at known stuff. Either the graphic layout, the text, add a joke, something must be unexpected. The unexpected should be in a context very friendly and predictable: don’t take this as a hint to start surprising the user in general with developers tricks on the interface. Just “going wild” is a commonplace too, and won’t work.
Consider also this case: a bored PR man is taking a look to a set of sites, all with their plain obvious marketing hypes and strong words. Then it comes to your site and… finds something different, interesting…
Design page and publish it
Once designed and published, ask for reviews, test page speed and wide compatibility with the various tools which can be found online. The home page speed in loading and browser type and screen resolution compatibility is important. Put a beta of your page online, with Google analytics on it, and analyze how many people in % get to your “enroll” or “download”. Try variations. Buy a test at http://www.usertesting.com or similar services. Remember to get someone to read this blog and then evaluate the scorecard against your draft. Good luck!
End of part 1 – what is in part 2
In order not to make this blog post uncomfortably long, the following part, concerning how we in Open Lab applied the principles above, is published here, in a second blog post.
A note on how to give titles blog posts: the first title of this post was “Writing an effective product homepage”; but for the very reasons explained in this same blog post, this wasn’t a good title. A candidate title was “Turn homepages from feature reports to ’short novels’ “, but that is a bit cryptic, so the one I choose is the one above, “Get visitors to read and remember your home page”, which talks directly about what you gain from this post, instead of indirect advantages through features.
2 comments