quinta-feira, 13 de janeiro de 2011
sexta-feira, 19 de novembro de 2010
How to Turn a Service Business into a Product Business
Perdão por não traduzir.
Jason Fried co-founded 37signals in Chicago as a three-person web design shop. And while it provided a decent living for him, the work itself lacked a certain satisfaction. “I found project-based consulting frustrating because we would work on a site for months and hand it over to the client, who would inevitably make changes and drag us through their politics,” he says. “It was rare that what we actually built saw the light of day.”
That frustration didn’t prevent 37signals from becoming successful. But as their projects grew larger and more complex, Fried and co-founder, David Heinemeier Hansson, found themselves looking for a piece of software that could help them better manage jobs among a growing network of staff and contract help often operating from different locations. Having evaluated a number of off-the-shelf tools, they decided to build a simple piece of project management software for their own internal use.
Then a funny thing happened: 37signals’ clients saw the simplicity of the software and started asking where they could buy it. It wasn’t long before Fried and his partner realized they had built a product that might have mass appeal. They polished it up, gave it the name Basecamp and, through their blog, announced its availability. A year later, Basecamp was more profitable than the web design business, and so 37signals stopped being a service business and started being a product business.
Today, tens of thousands of small businesses use 37signals software, and the company hasn’t built a website—other than its own—since 2006.
Making the Switch
When I recently interviewed Fried, also the co-author of the New York Timesbestselling book Rework, I was reminded of my former research company, Warrillow & Co., where we spent seven years as a project-based service business before we redesigned our model into a subscription-based product company. In my case, changing from a service to a product business made it more predictable, enjoyable and ultimately sellable (Warrillow & Co. was acquired by the Corporate Executive Board in 2008).
In the case of 37signals, Fried has no plans to sell but loves the freedom of running a product company. “When you’re a consulting business, you have to say yes to big clients, who end up telling you what to do. You become beholden to the giant corporation who is paying you $60,000 for a project,” he explains. “I love the feeling of control I have now. We build the best products we can for tens of thousands of customers. We try to make decisions that will benefit all of our customers, not just one giant corporation waving a big check.”
Based on my conversation with Fried, coupled with my own experience, here are four steps for turning a service business into a product business:
Step 1: Develop a Subscription Offering
In the case of 37signals, customers buy software on a subscription model. Under such a system, customers pay a small amount each month, so Fried and Hansson can predict their revenue well into the future. Predictable future revenue diversified among many customers gave 37signals the courage and resources to eventually turn off its service business.
At Warrillow & Co., we went from project-based consulting to having a single subscription to our research, which allowed us to see how our revenue was shaping up.
Step 2: Build an Audience
37signals had authored a popular blog for seven years before it announced Basecamp to readers. With a direct line to thousands of daily readers, 37signals was able to use the blog as its primary marketing vehicle to sell subscriptions.
At Warrillow & Co., we had been running a conference since 1999, so when we made the switch to the subscription model in 2005, past attendees made a natural audience for us.
Step 3: Don’t Give Yourself an Out
In a service business, clients always take priority, so it is hard to find the time to work on your product offering. In the case of 37signals, it needed project management software to better serve its clients, so it had a natural motivator: either develop the product faster or risk losing clients.
At Warrillow & Co., we did not have such a built-in sense of urgency, so we had to manufacture it: we quit accepting consulting projects cold turkey, which was made possible because we charged tens of thousands of dollars upfront for an annual research subscription. Once we had a couple of subscribers, we had the money in the bank to finance the drop in consulting revenue.
Step 4: Start Saying No
It took a year for 37signals to build up enough subscribers to start turning away projects. Fried remembers the day the company stopped offering consulting services: “It was so satisfying to know we were in control of our own destiny. We didn’t need to grovel for business and kowtow to clients anymore.”
For me, it was tempting to accept consulting projects, but saying no triggered the opportunity for us to talk about our subscription. We would explain to prospects that we did not offer custom consulting but would go on to describe how our subscription offering could help solve their problem.
The Jib
The best way I can describe the feeling of making the switch from a service to a product business is to imagine completing a jib turn in a sailboat. Rather than “coming about” and slowly stalling the boat’s progress by pointing its nose into the wind, the jib requires the captain to yank the tiller toward his or her body.
The jib is a sharp, violent turn and requires a strong stomach. When things get tough, you must override your instincts and continue to yank the tiller toward you until the turn is made and you’re safely on the other side.
Moving from service to product requires an equally strong stomach as customers will inevitably keep asking you to provide your service. But if you can make the switch, the reward on the other side is the sense that you own a business you control. You, not some overbearing client, decide what you sell, to whom, when and how. If entrepreneurship is about the freedom to be your own boss, then a product business is the ultimate escape.
quinta-feira, 29 de julho de 2010
Passing The Holy Milestone: How To Meet Deadlines
For too many projects, there comes a time when every action taken, every decision and sacrifice made, is spurred on by pressure to finish. Tempers seem to shrink along with the available days, talk about “high standards” gives way to “good enough,” and people realize that deadlines are aptly named. During the last-minute crunch, someone may well wonder, how did it come to this? Could it have been prevented? Every Web project has deadlines. But not every designer or developer deals with them the same way.
[By the way, did you know we have a brand new free Smashing Email Newsletter? Subscribe now and get fresh short tips and tricks on Tuesdays!]
What Causes A Deadline To Break?
Because a deadline marks the end of a project, everyone involved in the project must understand the deadline’s role. Most projects follow a schedule or have an estimated date by which they must be completed. The concept is simple then: when the work takes longer than expected, deadlines get missed.
A deadline is the end point of a time estimate, making it a known quantity. But how long will the work actually take to get done?
Of course, projects can be more complicated in their details. Unexpected technical problems and unanticipated changes will affect the amount of work required. Sometimes other tasks take priority. Sometimes the time estimate wasn’t considered carefully enough.
Whatever the cause, too much work needs to be done in the available time. That’s the problem, but not the challenge.
Rate Deadlines By Severity Of Consequences
The hardest deadlines are tied to events that cannot be moved, such as a date promised to the public, an upcoming trade show or a date stipulated in a contract. Retailers know that their holiday sales must end at Christmas, and theater owners can expect movie-goers to be upset if a 1:00 pm showing doesn’t start until 2:00. Likewise, if a website is tied to a time-sensitive event, its relevance is lost once the event has passed. Hard deadlines have clear consequences when missed.
Deadlines exist for a reason. The severity of the trouble caused by missing them increases dramatically after they have passed.
Deadlines tied to less public events are no less real, but a project will soldier on if the deadline slips. Company-imposed target dates, for example, rely less on public demand than on the temperament of managers. Meetings routinely start 10 minutes late because “something came up.”
The softest deadlines lack teeth or are set at some vague point in the future. That’s not always bad: not every missed deadline will cause a life-or-death crisis. But the same methods of solving the crisis apply. There are many strategies for handling a last-minute crisis. Most involve planning, setting priorities and knowing one’s limits.
Strategies For Preventing Deadline Crises
The beginning of a project is a great time to prevent problems later on.
The first solution is both obvious and difficult: do not take on a project that cannot be completed in the given time. Declining paid work requires discipline and confidence, but if the deadline is impossible, then the project may not be worth the money. Money cannot replace time.
Because deadlines with consequences are taken more seriously, keep a written list of definitive reasons why certain tasks must be completed by a given date. Losing money, customers and other assets create real incentives to work.
Schedule deadlines as specific tasks, not the ends of phases. Rather than “Content will be completed by 4 April 2010,” state “Review the content over lunch on 4 April 2010.” This ties the deadline to an event at which results must be shown. Mini-deadlines tied to specific events are more powerful than general statements.
Making up for minor time discrepancies during the course of a project is easier than facing a big shortfall when no time is left.
Plan For Unpleasant Surprises
Incentive may not be the problem, though. Unexpected problems cause many people to break deadlines. Their unpredictability make these problems hard to plan for, and good intentions don’t help you see the future. The key is to recognize that, whatever their nature, problems will likely occur.
If everything seems accounted for in the project plan, then invent a problem. Keep it realistic: “reshoot staff photos” is more likely than “spontaneous server combustion,” but it doesn’t really matter. The point is to create extra time to allow for a deadline crisis. One rule of thumb is to add between half and all of a project’s expected duration. That is, increase the full time that has been budgeted by between 50 to 100% to allow for surprises.
A plan of time estimates for major tasks in a project could look something like this:
| Task: | Time allotted: |
|---|---|
| Content audit | 15 hours |
| Develop content strategy | 15 hours |
| Make WordPress theme changes | 20 hours |
| Import data from old website | 15 hours |
| Test on multiple browsers | 5 hours |
| Total | 70 hours |
Being conservative, let’s take half of 70, which is 35. Now we invent a problem: say, having to retype all content from print-outs. Is 35 hours for that ridiculous? Perhaps. But obstacles are unexpected by nature, and they always steal time from an otherwise ideal budget.
Scheduling for unknowns is hard, but acknowledging that extra time is required will better align estimates with reality.
A line item needs to be added to the budget. It could be “Time to make changes” or “Allowance for unknowns.” The description isn’t as important as the fact that you have planned for surprises.
Is half of the original budget too much? It may drive cheaper clients away, but overestimating and finishing under the deadline is better than the alternative.
Mitigate A Deadline’s Threat By Adding Other Deadlines
Implement mini-deadlines within a project’s timeline. Mini-deadlines minimize last-minute problems by serving as checkpoints to gauge how far off track the schedule is, if at all, at certain phases.
- Start
While the project is fresh in everyone’s mind, a schedule for the other phases should be set. - First quarter
Everyone involved should have a sense of whether they can work together. Work begins, and the pristine project on paper comes up against the sticky details of reality. - Halfway point
The bulk of the work happens here. If you doubled your estimate to account for surprises, you would actually be aiming to launch the project right now. - Third quarter
If everyone pushed to launch by the halfway point, then almost everything should be done by now. But it rarely is. - Deadline
Launch the project. - Review
Win or lose, everyone should ask what should have happened at each phase of the project? What should have been done to meet each mini-deadline along the way?
Notice that mini-deadlines are based on time, not task. Tasks have a way of expanding, of taking up more time than planned, which mini-deadlines should prevent. Think of a mini-deadline as a chance to review the project’s timeline. While this approach may not entirely stave off a deadline crisis, it gives you opportunities to catch and correct problems along the way.
Plan Sacrifices In Advance
Every project has absolute requirements, which are essentially the reasons the project exists at all or the problems it is designed to solve. But many also have supplemental requirements. If a project requires A, B and C, then by all means include D, E and F, but only with the understanding that they might have to wait.
For example, a newsletter is an important marketing tool for an e-commerce website, but less important than an easy-to-use cart and secure log-in page. Likewise, the top priority for a photo gallery should be to present photos. If the deadline is looming and the AJAX is buggy, then perhaps the blog should wait.
Marking certain features as secondary provides relief when things go wrong. These features don’t need to be cut, but their deadlines should be later than those of the core project.
Practice
Measure the rate at which you work by timing how long you take to perform various tasks. You want to figure out how much time you need to comfortably perform each task, not how fast you can get it done.
For example, the schedule might allow for 30 minutes to create a favicon. But in reality, it consumes 8 hours.
Wait a minute. Eight hours for a measly 16×16-pixel graphic? Isn’t that… excessive?
That’s not the point. You’re not learning the rate at which you work so that you can gasp in embarrassment at the result. Workflow efficiency can be improved later. The question is, how much time are you comfortable with right now? In this case, it’s 8 hours.
Deadlines aren’t the problem. Problems arise when the work outweighs the allotted time. Learning how long you take to accomplish certain tasks is the best way to set a realistic schedule.
Conclusion
Not every deadline drama can be prevented, but even the worst can be dealt with professionally. Prepare for surprises, break up large tasks into manageable segments and prioritize. It’s a matter of respect: deadlines mean business. Do you?
How do you prevent deadline emergencies? What’s the worst problem you’ve faced under time pressure? What’s your greatest solution? Share your story in the comments below.
FONTE:http://www.smashingmagazine.com/
terça-feira, 27 de julho de 2010
Why Intelligent People Fail
Content from Sternberg, R. (1994). In search of the human mind. New York: Harcourt Brace.
1. Lack of motivation. A talent is irrelevant if a person is not motivated to use it. Motivation may be external (for example, social approval) or internal (satisfaction from a job well-done, for instance). External sources tend to be transient, while internal sources tend to produce more consistent performance.
2. Lack of impulse control. Habitual impulsiveness gets in the way of optimal performance. Some people do not bring their full intellectual resources to bear on a problem but go with the first solution that pops into their heads.
3. Lack of perserverance and perseveration. Some people give up too easily, while others are unable to stop even when the quest will clearly be fruitless.
4. Using the wrong abilities. People may not be using the right abilities for the tasks in which they are engaged.
5. Inability to translate thought into action. Some people seem buried in thought. They have good ideas but rarely seem able to do anything about them.
6. Lack of product orientation. Some people seem more concerned about the process than the result of activity.
7. Inability to complete tasks. For some people nothing ever draws to a close. Perhaps it’s fear of what they would do next or fear of becoming hopelessly enmeshed in detail.
8. Failure to initiate. Still others are unwilling or unable to initiate a project. It may be indecision or fear of commitment.
9. Fear of failure. People may not reach peak performance because they avoid the really important challenges in life.
10. Procrastination. Some people are unable to act without pressure. They may also look for little things to do in order to put off the big ones.
11. Misattribution of blame. Some people always blame themselves for even the slightest mishap. Some always blame others.
12. Excessive self-pity. Some people spend more time feeling sorry for themselves than expending the effort necessary to overcome the problem.
13. Excessive dependency. Some people expect others to do for them what they ought to be doing themselves.
14. Wallowing in personal difficulties. Some people let their personal difficulties interfere grossly with their work. During the course of life, one can expect some real joys and some real sorrows. Maintaining a proper perspective is often difficult.
15. Distractibility and lack of concentration. Even some very intelligent people have very short attention spans.
16. Spreading oneself too think or too thick. Undertaking too many activities may result in none being completed on time. Undertaking too few can also result in missed opportunities and reduced levels of accomplishment.
17. Inability to delay gratification. Some people reward themselves and are rewarded by others for finishing small tasks, while avoiding bigger tasks that would earn them larger rewards.
18. Inability to see the forest for the trees. Some people become obsessed with details and are either unwilling or unable to see or deal with the larger picture in the projects they undertake.
19. Lack of balance between critical, analytical thinking and creative, synthetic thinking. It is important for people to learn what kind of thinking is expected of them in each situation.
20. Too little or too much self-confidence. Lack of self-confidence can gnaw away at a person’s ability to get things done and become a self-fulfilling prophecy. Conversely, individuals with too much self-confidence may not know when to admit they are wrong or in need of self-improvement.
1. Lack of motivation. A talent is irrelevant if a person is not motivated to use it. Motivation may be external (for example, social approval) or internal (satisfaction from a job well-done, for instance). External sources tend to be transient, while internal sources tend to produce more consistent performance.
2. Lack of impulse control. Habitual impulsiveness gets in the way of optimal performance. Some people do not bring their full intellectual resources to bear on a problem but go with the first solution that pops into their heads.
3. Lack of perserverance and perseveration. Some people give up too easily, while others are unable to stop even when the quest will clearly be fruitless.
4. Using the wrong abilities. People may not be using the right abilities for the tasks in which they are engaged.
5. Inability to translate thought into action. Some people seem buried in thought. They have good ideas but rarely seem able to do anything about them.
6. Lack of product orientation. Some people seem more concerned about the process than the result of activity.
7. Inability to complete tasks. For some people nothing ever draws to a close. Perhaps it’s fear of what they would do next or fear of becoming hopelessly enmeshed in detail.
8. Failure to initiate. Still others are unwilling or unable to initiate a project. It may be indecision or fear of commitment.
9. Fear of failure. People may not reach peak performance because they avoid the really important challenges in life.
10. Procrastination. Some people are unable to act without pressure. They may also look for little things to do in order to put off the big ones.
11. Misattribution of blame. Some people always blame themselves for even the slightest mishap. Some always blame others.
12. Excessive self-pity. Some people spend more time feeling sorry for themselves than expending the effort necessary to overcome the problem.
13. Excessive dependency. Some people expect others to do for them what they ought to be doing themselves.
14. Wallowing in personal difficulties. Some people let their personal difficulties interfere grossly with their work. During the course of life, one can expect some real joys and some real sorrows. Maintaining a proper perspective is often difficult.
15. Distractibility and lack of concentration. Even some very intelligent people have very short attention spans.
16. Spreading oneself too think or too thick. Undertaking too many activities may result in none being completed on time. Undertaking too few can also result in missed opportunities and reduced levels of accomplishment.
17. Inability to delay gratification. Some people reward themselves and are rewarded by others for finishing small tasks, while avoiding bigger tasks that would earn them larger rewards.
18. Inability to see the forest for the trees. Some people become obsessed with details and are either unwilling or unable to see or deal with the larger picture in the projects they undertake.
19. Lack of balance between critical, analytical thinking and creative, synthetic thinking. It is important for people to learn what kind of thinking is expected of them in each situation.
20. Too little or too much self-confidence. Lack of self-confidence can gnaw away at a person’s ability to get things done and become a self-fulfilling prophecy. Conversely, individuals with too much self-confidence may not know when to admit they are wrong or in need of self-improvement.
segunda-feira, 26 de julho de 2010
Tank You For Making Innovation Work
In the tech industry, the earlier in the innovation process a developer works, the greater the prestige. Lower in the status hierarchy are developers who work on performance and scalability issues, build integrations with other systems, handle security issues, and (heaven forfend!) help the QA team set up test environments.
Of course, the customer has a much different set of priorities. Sure, new products and features are interesting, but their value is moot if the technology doesn't work. How many concurrent users can the system bear before it keels over? Are the big security holes plugged? Has anyone else run version 7.0.1.3 on Ubuntu 10.04? These questions determine whether a customer buys your product and how likely they are to remain a customer after they've tried to deploy it.
Remember The D In R&D
Some of the larger technology companies have decided to make a serious investment in fixing the problem. While sensitivity training might help some development teams better appreciate the contributions of some of their members ("Looks like the performance guy needs a hug!"), there's no replacement for a well-staffed, well-equipped, dedicated effort to ensuring that the technology works as advertised. Or, just as importantly, doesn't work as advertised, so that the customer knows what sort of configurations and use cases to avoid.
In the organization chart of companies like Intel and Hitachi, you'll find divisions called "labs." The term is technically accurate, but it's a little misleading in the subculture of the technology industry. We usually think of an entity like IBM's research arm as "labs," small groups of Very Smart People working on Very Big Ideas. However, "labs" can focus on the later phases of innovation, stressing the technology in real-world configurations and developing best practices for deployment and then communicating this information inside and outside the company. When the potential customer wants to be reassured about the risk of making an investment, the salesperson can credibly provide this reassurance.
It takes a dedicated, sustained, and substantial investment of people and resources to perform this service. Nevertheless, the business benefits are considerable. So why don't we hear about them more often? Part of the answer lies in our disproportionate interest in the early phases of innovation, where we create potential capabilities, and the later phases, when we make the technology work.
A Tale Of Two Tanks
When I used to have more office space, and I could clutter it with no end of gewgaws, I had two models of WWII-era tanks on my bookshelf. One was an American M4, more famously known as the Sherman. The other was a German Panzerkampfwagen VI, a.k.a. the Tiger tank. These two armored fighting vehicles represent different approaches to the technology design that are relevant to our discussion.
The Sherman was almost stereotypically American: simple, practical, and produced in enormous quantities. It was far from the best tank on the WWII battlefield, but it was a yeoman-like piece of hardware.
The Tiger was a far more powerful tank. Its 88mm gun outranged and outpunched the Sherman's 75mm gun. The Tiger was far more heavily armored, with predictable results: shells fired from the Sherman's inferior gun usually bounced off the Tiger's armor; the Tiger's beastly weapon punched holes through the Sherman's armor as if it were wet Kleenex. A one-on-one matchup between the Sherman and the Tiger was no contest at all.
However, real clashes between these weapons were rarely as simple as a one-on-one matchup. Sherman tank commanders learned how to swarm the Tiger, so that at least one American tank could get a shot at the Tiger's rear armor. (Of course, many Sherman crews died in these clashes, sacrificing themselves so that their brothers in arms could get behind the Tiger for the killing blow.)
Long before the two tanks reached the battlefield, the Sherman had already won many potential engagements, simply because the Tiger didn't show up. The Sherman had its weaknesses and even a few notable design flaws. It also had an enormous advantage: reliability. The United States produced hundreds of Sherman tanks every month, and when they reached the European theater, they quickly rolled off the container ships into battle. In contrast, the Tiger was a finicky beast, prone to breakdowns, requiring constant attention from its crews. From D-Day to the end of the war, Americans faced half of the Tigers in the German arsenal, due to the Tiger's constant mechanical problems.
Looking at the potential capabilities, the Tiger was a superior tank. Fortunately for the Allies, potential capabilities don't win battles.
We can make roughly the same observation about software and hardware: the vendor that "wins" is usually the one with technology that's both highly capable and reliable. If you want to increase your win/loss ratio, you might consider investing in the kind of lab that makes sure that the technology works and that the customer understands what to expect from it.
Of course, the customer has a much different set of priorities. Sure, new products and features are interesting, but their value is moot if the technology doesn't work. How many concurrent users can the system bear before it keels over? Are the big security holes plugged? Has anyone else run version 7.0.1.3 on Ubuntu 10.04? These questions determine whether a customer buys your product and how likely they are to remain a customer after they've tried to deploy it.
Remember The D In R&D
Some of the larger technology companies have decided to make a serious investment in fixing the problem. While sensitivity training might help some development teams better appreciate the contributions of some of their members ("Looks like the performance guy needs a hug!"), there's no replacement for a well-staffed, well-equipped, dedicated effort to ensuring that the technology works as advertised. Or, just as importantly, doesn't work as advertised, so that the customer knows what sort of configurations and use cases to avoid.
In the organization chart of companies like Intel and Hitachi, you'll find divisions called "labs." The term is technically accurate, but it's a little misleading in the subculture of the technology industry. We usually think of an entity like IBM's research arm as "labs," small groups of Very Smart People working on Very Big Ideas. However, "labs" can focus on the later phases of innovation, stressing the technology in real-world configurations and developing best practices for deployment and then communicating this information inside and outside the company. When the potential customer wants to be reassured about the risk of making an investment, the salesperson can credibly provide this reassurance.
It takes a dedicated, sustained, and substantial investment of people and resources to perform this service. Nevertheless, the business benefits are considerable. So why don't we hear about them more often? Part of the answer lies in our disproportionate interest in the early phases of innovation, where we create potential capabilities, and the later phases, when we make the technology work.
A Tale Of Two Tanks
When I used to have more office space, and I could clutter it with no end of gewgaws, I had two models of WWII-era tanks on my bookshelf. One was an American M4, more famously known as the Sherman. The other was a German Panzerkampfwagen VI, a.k.a. the Tiger tank. These two armored fighting vehicles represent different approaches to the technology design that are relevant to our discussion.
The Sherman was almost stereotypically American: simple, practical, and produced in enormous quantities. It was far from the best tank on the WWII battlefield, but it was a yeoman-like piece of hardware.
The Tiger was a far more powerful tank. Its 88mm gun outranged and outpunched the Sherman's 75mm gun. The Tiger was far more heavily armored, with predictable results: shells fired from the Sherman's inferior gun usually bounced off the Tiger's armor; the Tiger's beastly weapon punched holes through the Sherman's armor as if it were wet Kleenex. A one-on-one matchup between the Sherman and the Tiger was no contest at all.However, real clashes between these weapons were rarely as simple as a one-on-one matchup. Sherman tank commanders learned how to swarm the Tiger, so that at least one American tank could get a shot at the Tiger's rear armor. (Of course, many Sherman crews died in these clashes, sacrificing themselves so that their brothers in arms could get behind the Tiger for the killing blow.)
Long before the two tanks reached the battlefield, the Sherman had already won many potential engagements, simply because the Tiger didn't show up. The Sherman had its weaknesses and even a few notable design flaws. It also had an enormous advantage: reliability. The United States produced hundreds of Sherman tanks every month, and when they reached the European theater, they quickly rolled off the container ships into battle. In contrast, the Tiger was a finicky beast, prone to breakdowns, requiring constant attention from its crews. From D-Day to the end of the war, Americans faced half of the Tigers in the German arsenal, due to the Tiger's constant mechanical problems.
Looking at the potential capabilities, the Tiger was a superior tank. Fortunately for the Allies, potential capabilities don't win battles.
We can make roughly the same observation about software and hardware: the vendor that "wins" is usually the one with technology that's both highly capable and reliable. If you want to increase your win/loss ratio, you might consider investing in the kind of lab that makes sure that the technology works and that the customer understands what to expect from it.
Assinar:
Postagens (Atom)