RSA Animate - Drive: The surprising truth about what motivates us

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.

Beba na fonte: http://www.inc.com/guides/2010/11/how-to-turn-a-service-business-into-a-product-business.html

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.

1. Start
   While the project is fresh in everyone’s mind, a schedule for the other phases should be set.
2. 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.
3. 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.
4. Third quarter
   If everyone pushed to launch by the halfway point, then almost everything should be done by now. But it rarely is.
5. Deadline
   Launch the project.
6. 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/

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.

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.

How Product Management Can Save SaaS

With the shift to Software as a Service for many applications the need for strong product management is more apparent than ever. Here at the 280 Group we use several SaaS applications, and to be frank most of them are poorly implemented and remind me of the early days of desktop applications.
Here are just a few of the places where product managers can add tremendous value in a SaaS environment:

• Be responsible for the whole product. No one understands the product, customer and business better than the product manager. And no one has a better holistic view. Each department (sales, support, etc.) has their own agenda that is perfectly logical from their point of view. But the if unchecked when decisions are made it can result in a terrible experience for the customer.
• Filter out the vocal minority. Many SaaS companies are using built-in surveys and discussion forums to gather information as the basis for prioritizing features in their releases. This is a valuable source of data, but by definition the customers who are contributing are self-selected and most likely won’t reflect what your average user really cares about. If you don’t bring in additional data you run the risk of building a product that makes your power users happy but leaves the other 97% of your customers scratching their heads.
• SaaS applications can change too rapidly. I am sure that each individual decision to add new features rapidly and change menus, etc. is well-justified within each SaaS company. The problem is that at the 280 Group we run multiple SaaS applications. Between all of them at least one changes every week or so. As a small business owner I don’t have the time or desire to re-learn how to do tasks or to absorb new features and functionality constantly – I have a business to run. Imagine if every time you opened up Microsoft Word the menus had changed. Product Managers need to specify the most important use cases and ensure that new releases don’t interrupt their customer’s work flows. And they need to understand the environment of their customers and how often customers can really digest new changes. Just because your team is doing one month sprints doesn’t mean you should necessarily provide a new release every month.
• Implement usage monitoring software and use it wisely. Since you can monitor what features are being used in a SaaS environment it can be valuable to aggregate the data and use it in product decisions. However, you have to balance this with the fact that there may be features in the product (or that need to be added to the product) that users can’t find and/or don’t know about. When Microsoft did a survey to see what should be added to MS Word in Office 2007 8 out of 10 of the top requests were features that were already in the product that users didn’t know about or couldn’t find! Product managers need to combine usage data with common support questions, queries in the help system and customer research to determine what the right mix is rather than relying only on usage data.
• Set the long-term vision and strategy for the product and make sure that short-term decisions are aligned with it. With the increasing use of Agile and the short development cycles of SaaS it is easy for a team to become far too focused on the short-term list of features to implement. The danger in this is that you won’t necessarily build a product that will be competitive a few years out. Tacking features on based on what seems the most important thing this month can lead you to both an architecture that can’t support large-scale necessary changes and a product that starts to look like a swiss army knife.
• Don’t ship beta features in a product that customers are paying for. When we are paying a premium for a SaaS applications nothing pisses us off more than seeing a feature listed as “Beta”. What does that mean? Can we count on it? Does it work correctly? Product Managers need to make the call as to whether a feature is implemented and tested to the point where customers can rely on it. If not, don’t release it. As SaaS matures I am hopeful that the quality of the applications will improve and that there will be more of a focus on the user.
• Get trained and up-to-speed on how to work more effectively with your team if they are doing Agile development. Agile environments require different skill sets than waterfall, so make sure you learn about effective product management in that environment. You might want to read Agile Excellence for Product Managers or take a course on Agile Product Management Excellence.

As SaaS matures I am hopeful that the quality of the applications will improve and that there will be more of a focus on the user. Product managers will be key to making this happen.

FONTE: http://www.280group.com

“How To… Retire a Product Gracefully”

As Product Managers one of the toughest challenges we face is to determine when to withdraw our product from the marketplace. Its much easier to build and launch a product then to discountinue a product, especially if there are a few remaining customers still using the product. I have personally closed a handful of services and for me, it was sad to close a service which I had spent much time building. However, there comes a time when it makes good business sense to cease the service offering, to stop selling and supporting the product in the marketplace.

So When is the Right Time?

Closure of a service or product should come as no surprise. The Product Manager will see clear signals that the product’s ability to satisfy consumer needs, to generate sales and subsequently revenue is no longer sustainable.
The following signals should give the Product Manager an indication that its time to reconsider the product’s viability in the marketplace:

1. If the product is mature in its lifecycle and is seriously heading towards the decline stage. There are other solutions in the market that better solve the same customer needs.
   Dial Up Internet for example is one service which is past its maturity stage and various Broadband services resolve the same customer need. The video player for example also falls into this category with the onset of DVD player.
2. When the business changes its course and consequently, so does the product strategy.
   For example, a company may decide to stop servicing the business market and focus its efforts only on the consumer market. B2b products may consequently be withdrawn from the market as a result of this shift in strategy.
3. The cost of the product increases significantly because the economies of scale previously enjoyed is diminishing and the company is unable to increase the selling price of the product.  For example, if the cost of maintaining an Internet network becomes too expensive because the number of subscribers on the network has reduced but the price of the Internet retail service is extremely competitive, the company may have to discontinue the Internet service to its customer base.
4. The product or service the company created simply did not meet the needs of consumers. Efforts to aggresively market the product or service have not made any difference to the subscriber numbers or volume of purchases. The Apple Newtown springs to mind in this instance. Touted as the future of computing in 1993 it came with a price tag of $1000 and a whole host of problems. It was withdrawn from the market 6 years later.
5. Customers switch to a competitor product with better features, with a better product experience or a more competitive offering.
   Will the Blackberry be replaced by the iPhone or an Android phone? Interactive TV casual games that are available on many Satellite and Cable networks for example also fall into this category. There are better casual game experiences on offer and customers have preferred to switch to competitor

So the signals are clear and the decision is here. How do you go about retiring the product… gracefully?

Taking the Next Step

This time its super important to put ‘pen to paper’.  When closing a service or discontinuing a product, you’re affecting real, more than likely paying customers.
We recommend preparing a Product Exit Plan before a final decision is made. The Product Exit Plan should be tailored to the situation and the particular product.
Remember, you’re writing this plan from a Product Manager’s perspective and should pay attention to the needs of the consumer.
A standard Product Exit Plan should consist of:

1. Brief description of the product and its history.
2. Reasons for discontinuing the product.
3. Financial impacts on the business of discontinuing the product.
4. The exit plan itself describing the process of discontinuing the product. Include an exit date and work back from that point.
5. The communications plan to customers. There might a migration component if you have a substitute product.
6. The communications plan to internal sales and customer service teams and other external sales channels.
7. Risks of your exit plan and any contingencies to mitigate the risks.

When this plan is approved, the company should organise for the closure. Generally speaking closing a service or discountinuing a product involves a team of people. The Product Manager plays a role but should not be responsible for all aspects of the project.
Creating a Product Exit Plan provides a structured framework for Product Managers to consider all aspects of the product closure.
Closing a product is not easy but sometimes it has to be done.

Fonte: Bainmates (http://www.brainmates.com.au/)

Real Unfair Advantages

This is Part 2 of the series: 5 lessons from 150 startup pitches.

What if someone copies your awesome business idea?

About twenty people on Answers OnStartups have asked this question in one form or another:

When I meet an angel investor, he may ask: "What if a big company copies your idea and develops the same website as yours after your website goes public?"
How can I answer this question?

No, the question is: What are doing now knowing that a big company will copy your idea?
No, wait, the real question is: What are you going to do when another smart, scrappy startup copies it, and gets $10m in funding, and is thrice featured on TechCrunch?
No, wait, I'm sorry, the real question is: What are you going to do when there are four totally free, open-source competitors?
No wait, I forgot, actually the question is: What happens when employee #2 makes off with your code and roadmap and marketing data and customer list, moves to Bolivia, and starts selling your stuff world-wide at one-tenth the price?
The good news: There are good answers to these questions!
The bad news: Almost no one I talk to has good answers, but they think they do. And that's fatal, because it means they're not working towards remedying that situation. Which means when one of the above scenarios happens, it will be too late.

The first step is admitting you have a problem.

Last week I detailed the most common misconceptions about competitive advantages, so go read that if you haven't already.
To summarize: Anything that can be copied will be copied, including features, marketing copy, and pricing. Anything you read on popular blogs is also read by everyone else. You don't have an "edge" just because you're passionate, hard-working, or "lean."
The only real competitive advantage is that which cannot be copied and cannot be bought.
Like what?

Insider information

They say the only way to consistently make money on Wall Street is to have insider information. Unfortunately it's not a joke, and although it's illegal (and people occasionally go to jail for it), those in the know will tell you it's the norm.

Fortunately, using intimate knowledge of an industry and the specific pain points within an industry is a perfectly legal unfair advantage for a startup.
Here's a real-world example of how this advantage manifests. Adriana has been a psychiatrist for 10 years; she understands the ins and outs of that business. During a lull in her practice she got a serendipitous opportunity to shift gears completely and ended up leading software product development teams.  (Turns out that for big-business project management it's more valuable to be a sensible thinker and counselor than to be an expert in debugging legacy C++ code.)
Now Adriana has an epiphany: Traditional practice-management software for psychiatrists totally sucks; she knows both the pain points and the existing software first-hand. But now she has the vision and ability to design her own software, capitalizing on modern trends (e.g. a web application instead of cumbersome installed applications) and new interpretations of HIPPA regulation (which allows web-based applications to store medical records like patient histories).
Adriana holds a unique position: Expert in the industry, able to "geek out" with her target customer, yet capable of leading a product team. Even if someone else saw Adriana's product after the fact, it's almost impossible to find a person — or even assemble a team — who has more integrated knowledge. At best, they could copy. Of course by then Alicia has moved on to version two.

Single-minded, uncompromising obsession with One Thing

A popular comment on the previous post was that a "Unique Feature" could be a competitive advantage in some circumstances. Some examples of a feature being a company's primary advantage are:

• Apple compromises everything in the name of design. Their products are over-priced (magically being profitable at half the price 12 months after release), buggy (how many iOS debacles have there been?), and every experience I've had with their tech support has been atrocious, but man their stuff looks and feels nice! (I'm typing this on an Air and there's an iPhone in my pocket, so no Apple fan-boy mail please.)
• Google's search algorithm was just better, therefore they won the eyeballs, therefore they were able to monetize. Sure Bing and Yahoo are good now, but the advantage lasted long enough.
• Photodex is a little company you've never heard of I worked for in Austin in the 90's. We made an image browser with thumbnail previews so you didn't have to open each file individually to see what it was. (In the 90's, y'all, before that was built into all the operating systems!) Our advantage was speed. Not the best, not the most stable, didn't read the most formats, didn't have the most features, just "fastest." For many users of that product, speed wins; Photodex now makes tens of millions of dollars a year, and "speed" is still the only point on which they will not compromise.

However it's not enough for a feature to merely be unique (like my mini-browser) because it's still easily duplicated. Indeed, most of the innovations we've made at Smart Bear in the art of code review have already been duplicated by both commercial and open-source competitors.
Rather, this requires unwavering devotion to the One Thing that is (a) hard, and (b) you refuse to lose, no matter what.
Google has spent hundreds of millions of dollars on their search algorithm, the single biggest focus of the company even today, a decade after they decided that was their One Thing. They refuse to be beaten by competitors or black-hat hackers, whatever it takes.
37signals can build simple — almost trivial — software and earn three million customers because they absolutely will not compromise on their philosophy of simplicity, transparency, and owning their own company, and that's something millions of people respect and support. Competitors could build trivial web applications too (as Joel Spolsky is fond of saying, "Their software is just a bunch of text fields!"), but without the single-minded obsession it's just software with no features.
To remain un-copyable, your One Thing needs to be not just central to your existence, but also difficult to achieve. Google's algorithm, combined with the hardware and software to implement a search of trillions of websites in 0.2 seconds, is hard to replicate; it took hundreds (thousands?) of really smart people at Microsoft and Yahoo years to catch up. 37signals' ranting platform — a blog with 131k followers and a best-selling book — is nearly impossible to build even with a full-time army of insightful writers.
"Being hard to do" is still a true advantage, particularly when you devote your primary energy to it.
P.S. For more, here are detailed examples of how this mindset also sets up your sales pitch.

Fonte: A Smart Bear

Pick one and own it

What if your company were allowed only one advantage over the competition?
What would a sales call look like, starting with your 30-second pitch, then dealing with skeptical questions, trying to earn this potential customer's interest, respect, and eventually money, all with only one advantage?
Impossible, or just pointless?  Neither!

You should go through this exercise because this skill is valuable in every sales call. Sometimes you're defending the few advantages you have over a specific competitor. Sometimes you're arguing the virtues of small businesses over large ones. Sometimes you're defending your product against what the potential customer perceives as a glaring lack of functionality.
Hanging your hat on just one advantage that you can own completely is stronger than diluting your message across many advantages.
And it's not just in face-to-face sales calls either. Your homepage becomes laser-focused. Your advertisements become pointed, powerful, pithy, and other words starting with "p."  Your 30-second pitch becomes compelling. You know what to blog and Twitter about. Your 5-minute product demo drives home a single point. Everyone knows who you are and where you stand.
And at least on this one point, you're untouchable. Doesn't that sound nice? It is nice.
But don't you need lots of advantages to overcome sales objections and competition? No. Let's see how to riff off single advantages, using them to answer a range of skeptical questions and concerns.
If nothing else, this should get your juices flowing and make future sales calls and marketing messages more effective.

Most Expensive

You: We're the Cadillac tool — the most expensive, but also the best. I know, "most expensive" doesn't automatically imply "best!" But in our case you get what you pay for.
Customer: Hmm, I don't know, budgets are tight. We're thinking of going open-source — it's free.
You: Open-source is free like puppies are free. You don't write a check to get it, but you have to support it for life. Your employee's time is not free. Working around bugs is not free. Having nothing but the Web of Lies Internet to rely on for tech support is not free. See, we don't line our pockets with that revenue, we spend it making you maximally effective.  We answer the phone on the first ring. When you have a problem, we connect you directly with developers instead of hiding behind off-shore Level 1 support. We'll stay on the line with you at 3am as you work through a problem. We'll do a conference call helping you through best-practices on using the tool for your specific purpose. We do things open-source would never do.
Customer: OK, that's useful. But BigCorp offers 24/7 tech support too and they have consultants.
You: It's quality, not quantity. Let's get specific. We employ actual software developers for Level 1 tech support and email, so you're talking to someone who not only can answer every question but can even read the code to get answers. You're talking to someone who has the power and ability to change the code to fix a bug or add a feature. That's an inside track that no big company will offer. And consultants? Our consultants write blog posts about best practices. Our consultants literally live and breath with the entire team every day. Our consultants train with the top experts in the field, who we can afford because we're the Cadillac. You're not getting someone who realized they can turn a buck installing high-priced software — you're getting true experts giving you insight that only we can provide.
Customer: I'm also checking out SimpleCo's tool. They're much cheaper, and although they don't have as many features, it seems simpler to use.
You: Just because they do less doesn't mean they're easier to use. For example, one of the reasons we're expensive is that we integrate with 20 other software packages. That's great for you, because it means we interoperate with more of your other tools — including that tool you're going to buy next year but you don't know it yet. But it's not more complex for you, because if you don't use an integration it has zero impact on your day-to-day use. There's a myth that "more features are always more complex," but that's just bad user interface design. And yes, you guessed it, we can afford awesome user interface experts who help us avoid those mistakes.
Customer: But still, even if I agree with all that, I still have to justify the budget today.
You: When you factor in the cost of the tool, also factor in the cost of failing to be successful with the tool. To spend many months installing, integrating, training, learning, customizing, fighting, on the line with tech support, only to have it fail in the end — having to rip it out, then go through the whole process again with a new tool. Multiply that by the chance the tool will indeed fail. Sure it's possible that any tool could fail, but with us — more features, better support, expert help — it's less likely to happen. Oh, and besides the catastrophic expense, what's the effect on your personal career? What's best for you and your company is to bet on the best.

Obsessed with Quality

You: Software is so crappy nowadays, we expect failure. We expect bugs. We expect to be helpless, to just have to "deal with it." At AwesomeCorp, we say that's unacceptable.
Customer: Yeah.... so you're saying you have no bugs at all?
You: No, I'm saying we're maniacal about finding bugs, and when you find one we're incredibly fast at fixing them. It's not unusual to have a fix in under 24 hours. All software can have bugs, but no one is more committed to fixing them.
Customer: Well if that's true, that's good. But I'm currently trialing BigCorp's tool and they have more features than you. I don't know which we'll need, but I have a problem buying a tool that doesn't do much.
You: It sometimes sounds like "more feature bullet points" is automatically better, but you and I have used software that claimed to have lots of useful features that didn't really work in reality. Usually the more features a product has, the worse each feature is. Try uploading a 1gig file to BigCorp's tool — oops, it breaks! To us, saying you have a feature when in reality it's full of holes is dishonest. We'd rather know we have fewer features that we actually stand behind rather than claim to have features that are just incomplete.
Customer: OK, I can appreciate that, but what about OpenSourceOrg's tool? I know it doesn't do quite as much as yours, but free is free!
You: Yup, free is free... until you run into a bug. It's free until it crashes. It's free until you notice there's incorrect data floating around. It's free until you need something and there's no one to ask. Of course they say "you can fix that bug yourself" or "you can add that feature yourself," but that ain't free! And even if you invest the effort, if they don't accept your patch you'll constantly have to re-patch when you get updates. Bugs are a reality, and that's when open-source starts to become non-free in a hurry. We, on the other hand, never charge you for bug fixes, even years later, because we're 100% committed to quality code.

Small Company

You: If you haven't worked with a small company before, you're in for a nice surprise: Smart people you can actually talk to, people who care about what you need, people willing to go out of their way to make sure you're successful.
Customer: I get that, but little companies fail all the time. How do I know you'll be around to give me that great support?
You: You say that as if big companies are stable during recessions and accounting scandals! You say that as if big companies don't cut entire product lines if they're not profitable, or sell them off even if they are. It's impossible to know when a big company is about to discontinue your product, and it happens all the time.
Customer: You say you have great support, but BigCorp is the one with 100 developers and support engineers willing to help me.
You: "Willing" to help you perhaps, but able? Typically the software developers are shielded by "Level 1 support" — people without power, certainly not the power to get your feature requests into the pool. In fact, wouldn't you agree most tech support feels like a shield rather than a help?  And even if you get a bug into the pile or a feature onto the list, big companies release new versions infrequently, so you might have to live without it for a year. Not us. You get to complain directly to the engineers who can fix the problem in weeks — or sometimes days.
Customer: But they have 24/7 support. Do you have that?
You: No, we don't pay folks we've never met $1.25/hour to answer the phone at 3am PST so they can tell you to reboot your machine and RTFM. Instead we pay actual software developers $70/hour to talk with you in person about exactly what's wrong, either solving the problem or getting it fixed ASAP. Sometimes we even write special code just to get you running again, tiding you over until a proper fix is released. Try getting that from BigCorp!
Customer: Well if that's true, that's good. But BigCorp also has more features than you.
You: Do you really want your tools to have "more features," or is it really that you want your specific needs met, and "more features" could potentially mean that more of your needs are met? We believe the point of software is to solve your problems and make your life better without incurring too much new expense in time and money. Even assuming BigCorp's has one or two features you like today, what about in six months when you're deep into the tool and realize there's 10 more things you really want? Do you expect them to add half of those to their next release? Because that's exactly what we're going to do — hold proactive meetings to find out what you need to be most productive, and agree to add those as soon as we can. Don't ask "Which tool will satisfy my needs today," ask "One year from now, which tool will be satisfying my needs, including the ones I can't foresee?"
Why try to defend 10 points when you only need one or two to make your case?
Why not focus your message, focus your behavior, focus your look-and-feel, and focus your sales pitch?
It's already hard enough to stake out a niche in this massive world! Don't dilute your message.

Fonte: A Smart Bear

Prototipe

O "Design Thinking Process" (que eu citei no meu último texto aqui no blog) pode ser utilizado na criação de um produto de software. Encontrei mais um vídeo na internet que é a pura aplicação do processo no desenvolvimento de software.



É o mesmo modelo que utilizamos na Nextt (sim, propaganda novamente) e é o modelo que eu, nos meus curtos 10 anos de experiência, alego ser o menos suscetível a problemas.

Um produto deve ser bem pensado, testado, aprovado, revisado antes de ir pro mercado. Na indústria de software é fácil enxergar quem teste o seu código, tenha um processo ótimo, mas não valide a visão do seu cliente. Tenta oferecer a solução sem antes validar que está realmente entendendo o problema do cliente. O mais importante é esquecido!

Tenho certeza que para outros produtos que não software, problemas similares acontecem o tempo todo.

Prototipe. Valide.