PRODUTIZANDO

Full List - The 25 Most Influential Business Management Books - TIME

2011-08-12T12:34:00.000-07:00

Full List - The 25 Most Influential Business Management Books - TIME

‪Tesco Homeplus Virtual Subway Store in South Korea‬‏ - YouTube

2011-07-18T11:13:00.000-07:00

‪Tesco Homeplus Virtual Subway Store in South Korea‬‏ - YouTube

Momento Cultural: entendendo como funciona o monopsônio da Apple | MacMagazine

2011-07-05T09:31:00.000-07:00

Momento Cultural: entendendo como funciona o monopsônio da Apple | MacMagazine

When Is a Tech Company Dead?

2011-04-01T10:26:00.000-07:00

Last week, I had the chance to interviewAndy Bechtolsheim, co-founder of Sun Microsystems and many other game-changing companies. Whether it was time spent with him, or the news that Oracle was shutting down Sun.com, I’ve been dwelling on a morbid thought: the death of a technology company.

Not a day goes by when I don’t say or hear the following:

Yahoo is dead.
Microsoft is so dead.
Nokia is dead.

Upon hearing me say this time and again, my friend Pip Coburn, a veteran technology investor and author of The Change Function, asked me, “What do you mean by a company being ‘dead?’” We had a long conversation, which he summed up in a newsletter to his clients.

Silicon Valley is all about the New New Thing that certainly no one aspires to gracefully age! A couple weeks ago at lunch my friend Om discussed that this company and that company were “dead.” I finally said “Hey, Om, how are you using this West Coast version of a company being ‘dead’ because the companies you just mentioned are large, still growing a touch and seem quite stable? On the East Coast we reserve “dead” for companies like Eastman Kodak or Circuit City. Do tell…”

My response to him was pretty simple — on the West Coast (or at least in Silicon Valley), we tend to live in the future. The present isn’t as interesting to most of us who live here, mostly because that would mean accepting the status quo. Instead, guys like Mark Zuckerberg and Jack Dorsey want to rearrange the world to fit the future they want to live in.

Because of this obsession with the future, we tend to get excited about companies long before they’ve proven their ideas, developed business models or generated revenues (never mind profits). The intellectual energy of a startup or a founder is what gets him/her millions of dollars for virtually nothing.

I told Pip:

We can tell when a company will no longer be involved in generating the next round of real energy in the tech/internet world, and when they hit that point, they never come back to be an energy creator and so they are “dead” in West Coast minds.

So when I (or someone around here) proclaim that Microsoft or Yahoo is dead, it doesn’t necessarily mean that the company is without revenues or without a business. Both Yahoo and Microsoft are making a ton of money and will do so for the foreseeable future. Microsoft makes so much money that it even gives dividends to its shareholders.

The idea of aging gracefully makes a lot of sense in general, but in the realm of technology it doesn’t make much sense. What about Oracle and IBM as examples of large undead companies, you might ask? I would argue that Oracle and IBM are outliers.

IBM, despite its size, has managed to reinvent and reboot itself many times — from a typewriter maker to mainframe computers to desktops to a services-driven company. IBM has used its massive R&D spending to become young again and again. The IBM of today is very different from the IBM I first started covering as a young reporter. Oracle is an exception mostly because of its leader, Larry Ellison, who is a businessperson at heart, and who knows technology and perfected a buy-and-grow strategy for his company.

What these two examples show is that even an older company can thrive if it:

Successfully reboots and redefines itself for the future, so it can attract the talent to get it to the future.
Is run by a technologically-savvy founder.

A technology company hits the “dead” phase when it’s unable to stop the bleeding of talent or attract the new talent it so desperately needs in order to create energy. The problem isn’t unique to large companies; even small startups hit that “dead” phase and lose their intellectual energy.

While bureaucracy and over-dependency on certain ideas is a problem for large companies, small companies often die because of a few primary reasons: lack of money, lack of leadership or lack of market. They are all intertwined.

If there’s no market, the money (revenues or venture capital) dries up, which means talent escapes to find new opportunities. Lack of leadership means lack of ability to make money and attract or retain talent. Lack of money — well, that means you don’t have the oxygen to stay alive.

Or as Pip said, “To paraphrase the immortal words of Billy Crystal in The Princess Bride, West Coast dead means still barely alive!”

Fonte: http://gigaom.com/ By Om Malik Mar. 31, 2011, 8:16am PT

Don’t Gather Requirements, Drive Them

2011-03-09T13:21:00.000-08:00

How to be A Good Product Manager (which is a phenomenal blog, by the way, and wish I had written most of the content) has this excellent post about requirements, and it applies requirements gathering. One of the traps that we fall into as consultants is that with certain clients, we go into the mode of just gathering requirements and not advising what the requirements should be (read: let’s design the Pontiac Aztek, quite possibly the ugliest car on the road).

Just gathering requirements is a bad idea. Advising on requirements is a better idea, because that’s how you add value.

Sure it’s like herding cats, but the reason many consultants are valuable is there’s some wonderful insight that they may have, however small it may seem, that adds phenominal value for the client. That’s why they are paying consultants what they do.

How so? We start the conversation about what the direction should be, even if it’s the wrong direction at the start. One of the essential points that the article makes is that in many cases, the customer has no idea what they want (a car), and what they may get may be anything from a Hummer or a Prius.

Our job is to ask questions that will lead to developing a better product, and not necessarily questions that lead to what we think the product should be. Many scenarios, it’s impossible to satisfy all parties, because they may ask for a car that is great for the environment (the Prius) and can run over people (the Hummer), because the requirements are conflicting. Our job is to find the best solution, not the solution that meets the needs of everyone.

Or what do they say — trying to make everyone happy will make no one happy?

Beba na Fonte: http://www.usabilitycounts.com/2008/05/08/consultant-thursdays-dont-gather-requirements-drive-them/

Hacker cria nova forma de grampear iPhones e smartphones Android - Segurança - IDG Now!

2011-01-17T10:14:00.000-08:00

Hacker cria nova forma de grampear iPhones e smartphones Android - Segurança - IDG Now!

Everyone is a product manager « Lead on Purpose

2011-01-13T05:04:00.000-08:00

Everyone is a product manager « Lead on Purpose

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

2010-11-19T19:50:00.000-08:00

How to Turn a Service Business into a Product Business

2010-11-19T14:26:00.000-08:00

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

2010-07-29T09:15:00.000-07:00

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/

Why Intelligent People Fail

2010-07-27T11:38:00.001-07:00

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

2010-07-26T11:00:00.000-07:00

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

2010-07-26T04:33:00.001-07:00

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”

2010-07-19T13:54:00.000-07:00

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:

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.
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.
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.
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.
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:

Brief description of the product and its history.
Reasons for discontinuing the product.
Financial impacts on the business of discontinuing the product.
The exit plan itself describing the process of discontinuing the product. Include an exit date and work back from that point.
The communications plan to customers. There might a migration component if you have a substitute product.
The communications plan to internal sales and customer service teams and other external sales channels.
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

2010-07-19T11:20:00.002-07:00

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

2010-07-19T11:20:00.000-07:00

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

2010-01-23T10:11:00.000-08:00

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.

Design Thinking

2009-12-27T07:08:00.000-08:00

Existe um tabu sobre a palavra design no Brasil, que nos limita a pensar em "estilização" mas o verdadeiro sentido na língua inglesa vai muito além. Design é projetar, é transformar uma idéia em algo palpável, é resolver um problema.

A palestra abaixo fala sobre o Design Thinking Process, descrito na wikipedia como "um processo para resolução prática e criativa de problemas ou questões que procuram por resultados futuros improváveis".

É um processo simples, descrito de algumas formas diferentes em ocasiões diferentes, mas que todos parecem-se muito como o esquema apresentado na figura abaixo.

6 passos do Design Thinking Process, surrupiada daqui

Produtizar é fazer design. É pensar na solução de problemas, principalmente o problema de muitos.

Eu, que sou da área da computação, tenho passado muito tempo "batendo cabeça" na resolução dos problemas dos usuários dos softwares que desenvolvo, e visualizo com muita clareza este processo entrando em prática principalmente na concepção e também no desenvolvimento de software.

O mais interessante é que muitas empresas de desenvolvimento de software simplesmente não conseguem sozinhas abrir seus horizontes e pensar "fora da caixa", com um processo baseado num design centrado nos verdadeiros problemas de seus clientes. Para resolver este problema, está surgindo a Nextt.

Google, Apple e as teles

2009-12-21T13:46:00.001-08:00

Apple é uma empresa que vende experiência. Eles são uma marca “top”, se eles estivessem no ramo automóvel, seriam a BMW, Mercedes, Porsche e misturadas em um único carro. Possuem cerca de 12% do mercado de PCs no E.U.A.; porém no mercado de PCs top de linha (computadores portáteis acima de US$ 999 e desktops acima de US$ 699), sua participação chega a 91%.

Como eles entraram no mercado de telefonia móvel é uma história estranha e complicada, mas é melhor vê-los como um fornecedor de um produto que é um upgrade móvel do seu MP3 player (do seu ponto de vista), que se tornou altamente rentável. O ponto de vista original da Apple que a diferencia é a importância dada à experiência do usuário. Sem Mac OS X para diferenciá-los do restante do mercado, seus computadores seriam apenas PCs mais caros. Assim sendo, não deve ser nenhuma surpresa que a Apple e sua equipe de negócios tenham um único objetivo: manter o controle da plataforma do iPhone e fazê-la diferente (e impressionantemente boa).

A Apple não quer destruir as teles, pois eles só querem usá-los como um canal para vender a sua experiência do usuário. O Google, no entanto, é uma outra questão.

Google é uma empresa de publicidade. Seu modelo de negócio inteiro se baseia na quebra de barreiras de acesso que impedem o público de acessar ao conteúdo da internet lotado de anúncios do Google. Eles querem que o setor de comunicações móveis mude e que a concorrência passe a ser puramente disputada em largura de banda. Na verdade, eles seriam mais felizes se as teles forem embora, sumissem da frente dos usuários e todos estes passassem a utilizar terminais com acesso à dados ilimitado e de preferência grátis. Mais largura de banda, mais a navegação na web, mais anúncios, mais receita para o Google. Simples!

Pois bem, isto dito, vamos comentar sobre o anuncio do Nexus One ocorrido durante semana passada e que pode ser bem significativo para esta história. Se os rumores são verdade - que eles estão empurrando o Nexus a um preço baixo ou subsidiado, e fortalecendo a T- Mobile (o mais fraco dos cellcos dos E.U.A) para fornecer dados com uma tarifa móvel única acessível, acesso VoIP, além de roaming internacional -, então eles têm estão enviando um cavalo de Tróia para a indústria da telefonia móvel.

Talvez o Google está iniciando uma grande estratégia que poderá destruir o modelo de negócios das teles, que hoje se apresentam como um gateway de acesso super valorizado com conteúdo controlado com seu modelo de negócios sedimentado sobre contratos que prendem os usuários vendendo celulares premium (como o iPhone) em um contrato de fidelização.

Para o Google seria perfeito transformar o serviço 3G de dados (e, posteriormente, LTE) em uma commodity, como o serviço de hotspot Wi-Fi mais amplo e mais barato. Eles querem que os usuários comprem celulares baratos desbloquados e passem a utilizar SIM Cards de dados baratos, ao invés dos planos de voz antiquados e ineficientes mantido pelo telcos, então eles poderiam disponibilizar o Google Voice sobre ele, e, finalmente, realizar o negócio da Google para todas as suas mensagens de voz, bem como e-mail e acesso à web.

(Não é necessário comentar que isso vai levá-los a um conflito com a Apple. Até agora, o iPhone da Apple tem sido bom para a Google: os usuários do iPhone navegam muito mais na Internet - e vêem muitos mais “adsense” - do que usuários de telefones comuns. A Apple quer manter a experiência dos usuários e seguir vendendo através do jardim murado da App Store e do iTunes. A Apple é uma ameaça implícita ao Google porque ele não pode utilizar seus anúncios dentro do universo Apple)

A verdadeira mensagem aqui é que se o Google tiver êxito, a base o seu serviço de telefonia móvel em 2019 vai ser irreconhecívemente diferente daquela de 2009. Alguns dos maiores nomes do serviço de telefone (T-Mobile? Orange? Vodafone? AT & T? Verizon?) Seguiram o mesmo caminho Transbrasil, VASP dentre outros. Restarão apenas as teles com melhor infra-estrutra e interoperabilidade, que terão sucesso na adequação à este novo modelo de negócios, vendendo bits pelo preço mais baixo.

Provavelmente la por 2019, a tecnologia VoIP já deve prevalecer sobre o modelo atual, nós vamos ver algo não muito diferente de DNS ou endereços de e-mails no lugar do número de telefone. Então, o processo será concluído, a Internet terá comido o sistema de telefonia como conhecemos hoje.

O que é bom para a internet é bom para o Google. Neste momento, as companhias telefônicas não são boas para a internet. Se estou certo sobre a grande estratégia, o Googlephone vai mudar isso.

FONTE: Charlie´s Diary

Reunindo e Criando Idéias

2009-11-29T18:36:00.000-08:00

As idéias são como sementes das quais toda a grandeza cresce. Todo livro e cada empresa começou a partir da faísca de uma idéia. As idéias vêm em seu próprio tempo e em sua própria maneira. Quem compreende este princípio tem mais chances de encontrar um caminho seguro para o sucesso.
A chave para se beneficiar das ideias é saber capturá-las. Assim que perceber uma idéia, boa ou não, você deve anotá-las em um lugar onde você pode analisá-las e usá-las quando for a hora certa. Isto é importante porque você nunca pode controlar ou prever quando as idéias virão. Em seu audiobook “Capturing Million Dollar Ideas,” Richard Paul Evans, discute cinco coisas que você deve saber sobre suas idéias:

Sua vida é a soma das suas idéias;
Idéias são como borboletas, elas vêm a qualquer momento e elas aparecem sem aviso prévio, batendo suas asas bem na sua frente como se quisessem ser capturadas. Criar um local para capturar as idéias parece atraí-las em maior número. "A descoberta é união de um acidente com uma mente preparada", "Cultive seu jardim para que as borboletas venham até ele."
Não importa o quão espetacular ou brilhante seja uma idéia, eles têm vida curtíssima na sua mente; porém um valor incomensurável caso você consiga guardá-la.
Dificilmente você entende a grandeza de uma grande idéia até quando elas lhe faltam; algumas idéias necessitam serem amadurecidas como vinho ou queijo para passar a ter valor. Quase sempre você precisa crescer para entender o real tamanho das coisas.
Idéias geram outras idéias.

Comentando: As idéias são a matéria prima e o combustível para qualquer produto. O nosso maior desafio e dificuldade é captura-las e saber separar o joio do trigo, filtrando as potencialmente ótimas das não tão boas. Como podem ver, esse post poderia ser assunto de uma dissertação ou livro. O principal ponto é que, devemos captar as idéias independentemente da fonte ou da primeira avaliação que fazemos. Toda idéia tem valor, idéias geram idéias e nesse caso vamos quebrar um tabu da gerência de produtos, quantidade garante qualidade, devemos nos preparar para perceber a oportunidade e criar uma idéia ótima a partir de um conjunto de idéias que não pareciam tão boas até então. Ao longo do tempo as circunstâncias mudam, a tecnologia melhora e as oportunidades aparecerão de onde você menos espera. Quanto mais idéias você tiver juntado, mais preparado você estará para reuni-las para enfim aplica-las em um produto de sucesso. Seguimos em frente.

Não jogue os dados...

2009-11-24T03:04:00.000-08:00

"Com seis anos de experiência tocando a minha própria empresa de software, posso dizer que nada feito na Fog Creek aumentou tanto a nossa receita quanto lançar uma nova versão com mais features. Nada. O caminho ao 'chão de fábirca' das novas versões com novas funcionalidades é inegável. É como a gravidade. Quando tentamos Google Ads, quando implementamos vários esquemas com afiliados, ou quando um artigo sobre o FogBuzz apareceu na imprensa, nós mal sentimos o efeito no chão de fábrica. Quando uma nova versão surge com novas funcionalidades, a gente ve uma aumento repentino, inegável, substancial e permanente na receita".

Citação de Joel Spolsky, sócio da Fog Creek.

Se consumidores se deparam com a escolha de, digamos, um microondas Sharp ou Panasonic, metade deles escolherão o Sharp e a outra metade o Panasonic. Se eles precisarem escolher em um conjunto que possui um Panassonic e múltiplas versões de Sharps, então uma das duas coisas acontecem:

Se eles podem facilmente comparar os Sharps (por exemplo, porque eles diferem claramente em preço e outro atributo, como tamanha e potência), então mais pessoas escolherão os Sharp do que o Panasonic. Isto demostra como fornecer várias versões de um produto aumentar as vendas do produto.

Por outro loado, se eles não conseguem comprar facilmente os Sharps então o efeito é contrário. Por exemple, se um Sharp possui o prato giratório com velocidade ajustável, outro tem um sensor de umidade, outro tem menus programáveis e outro tem uma função de 'manter aquecido', os consumidores vão evitar os Sharp, rejeitar confusão e ir para o Panasonic. Isto mostra como fornecer multiplas versões de um produto pode diminuir suas vendas.

Ambos os trechos foram extraídos do livro "Don't Just Roll The Dice. A usefully short guide to software pricing", de Neil Davidson.

O livro está disponível para download grátis (sob licença Creative Commons).

Recomendamos.

Busque excelência em suas equipes - Lições em salas de espera sobre empreendedorismo

2009-11-18T20:07:00.000-08:00

Ultimamente tenho dedicado grande parte do meu tempo de espera em salas de aeroporto e vôos à leitura de livros que dizem respeito ao Google, à Apple além de outros sobre o novo paradigma de modelo de negócios e desenvolvimento de produtos que passou a existir após coincidentemente o BOOM dessas empresas.

Sinceramente não sei se a palavra coicidentemente que utilizei deveria ser escrita entre aspas, por que estas duas empresas seguiram a cauda de um movimento que estava se definindo e devido à uma atitude extremamente inteligente e inovadora no que diz respeito aos modelos de negócio e gestão de pessoas rapidamente deixaram de ser seguidoras desta "cauda" para se tornarem líderes nesta nova indústria. Criou-se uma magia em torno delas, não importa o quão visionária uma idéia ou produto possa ser, a priori, estas são prontamente aceitadas com entusiasmo pelos usuários.

Inovação, excelência em produto, sorte, enfim, não é minha intenção discutir as razões sócio-político-econômicas que levaram estas duas empresas, pelas quais confesso que tenho especial admiração, a se tornar o sucesso absoluto que são hoje; porém a verdade esta escancarada, o caminho do sucesso como do fracasso é conhecido, mesmo assim todos enfrentamos dificuldades para trilhar o nosso caminho de sucesso e digo mais, todos que estão na cauda desse movimento enfrentam absolutamente os mesmos desafios e dificuldades que nós.

Esta pequena introdução foi só para que todos saibam de onde vem minha inspiração para seguir-me motivado. Recentemente estava lendo uma matéria reveladora sobre empreendedorismo e entendi que ser empreendedor esta longe de apenas ter coragem de iniciar outro projeto paralelamente ou de forma disruptiva ao emprego convencional. Nesta ótima reportagem da Revista Voce SA, apreendi o conceito maior de empreendedorismo, de uma forma simples – como as boas definições deveriam ser – ser empreendedor é saber se manter motivado, preparado e atento para identificar as melhores idéias e oportunidades que muitas vezes passam desapercebidas, reuni-las, entender uma oportunidade maior e realizá-la, alcançando assim o sucesso. Pois bem, temos uma fórmula para o sucesso, ser empreendedor nos levará ao sucesso, mas como ser empreendedor sem abrir uma loja de armarinhos?

A resposta está nas pessoas. É preciso sempre buscar a excelência nos nossos processos, produtos, na nossa comunicação e principalmente em nossas equipes. Então por que deveríamos tolerar atitudes medíocres? Temos que manter a média de competência o mais alta possível, profissionais ruins estão sempre acomodados, desmotivados e por conseqüência pouco podem somar à busca do sucesso. Eles têm dificuldade em mostrar seu valor e sempre tecem comentários que desvalorizaram os seus companheiros e o ambiente de trabalho; numa tentativa desesperada de diminui a média até seu nível. Pois bem, a tolerância à este tipo atitude pode fazer com que a empresa perca seus melhores valores. Os melhores, os empreendedores sempre buscarão as melhores oportunidades, melhor seria ajudando a organização na busca do sucesso conjunto; porém quando o bom profissional se sente injustiçado, desvalorizado em relação ao mau profissional, esta busca por novas oportunidades se dará em outro ambiente que não o que a empresa lhe proporcia.

É necessário criar um ambiente ótimo para os bons profissionais, onde os melhores valores da organização possam exercitar seu empreendedorismo. Temos que aumentar a média de excelência das nossas equipes, abaixo o job simulation, devemos resolver ou banir o desempenho e as atitudes medíocres, dessa maneira muitas das perguntas, dúvidas e incertezas poderão ser resolvidas de uma maneira muito mais natural e criativa facilitando a conquista do tão almejado sucesso.

Engenharia de Serviços/Produtos

2009-11-16T16:21:00.000-08:00

Entender os usuários, entregar um serviço que os atenda, faz com que estes queiram ser seus clientes. Enquanto se preocupar com os objetivos do negócio somente obrigam seus clientes a utilizarem seus produtos e isso faz toda diferença...

Apesar do crescimento vertiginoso da indústria de serviços, grande parte dos esforços de engenharia e conseqüentemente Design continuam focado em objetos, seja em produtos ou evoluções do mesmo. Se é falta de visão do mercado sobre a aplicação da engenharia sobre o planejamento dos serviços ou vice-e-versa, não importa. Logo isso vai mudar.

Cada vez mais o preço dos seus serviços é determinado pelo mercado e temos que buscar se diferenciar da concorrência de qualquer maneira: ou agregando um valor que possa ser repassado ao mercado independentemente do que esta sendo definido pelo mercado ou melhorando os processos de maneira a aumentar a rentabilidade do mesmo produto preferencialmente em diversos clientes.

Fiz este parênteses para deixar claro que os produtos devem ter cada vez mais alto valor agregado e ser inovadores. Sabe-se que o preço dos produtos esta caindo, antes o valor de troca de um produto era muito alto e decaia com o tempo, tornando o valor de uso baixíssimo. A grande concorrência e os preços sendo definido pelo mercado demandam uma nova engenharia financeira para que um produto se mantenha viável invertendo a curva, quando se pensa em serviços o preço de troca é mais baixo e o preço de uso viabiliza um produto.

Se antes a preocupação com os objetivos de negócio era infinitamente maior que com os objetivos do cliente, quando se pensa em serviço, as preocupações com os objetivos de negócio e do cliente passam a se equivaler principalmente devido à necessidade de aumentar o valor de uso dos serviços/produtos. O Design tem um papel importante nesse caso, ajudando a gerar valor de uso ao produto.

Se antes buscava-se agregar valor ao produto melhorando as características do objeto; com a engenharia de serviços, um produto se viabiliza pela integração desse objeto em um contexto, de experiência, interação e serviços. Os produtos estão se tornando serviços e vice-versa. Entender os usuários, entregar um serviço que os atenda, faz com que estes queiram ser seus clientes. Enquanto se preocupar com os objetivos do negócio somente obrigam seus clientes a utilizarem seus produtos e isso faz toda diferença.

FONTE: TECNOLOGANDO

10 Maneiras de se Identificar e Prever um Desastre no Lançamento de um Produto

2009-11-15T18:34:00.001-08:00

O processo de introdução de um produto no mercado é uma empreitada séria, mas muitas empresas é meramente o processo de seguir um checklist ao término do desenvolvimento do produto. O lançamento é parte fundamental do processo é pode comprometer toda a expectativa de vendas se for mal planejado.

1. Não há metas para o lançamento. Quais são seus objetivos ao lançar o produto?

2. Qual a estratégia de lançamento e os deliverables que ela implica? Todos os times estão alinhados (vendas, marketing, suporte, etc)?

3. O plano contém prazos e expectativas inatingíveis? É bom ser otimista, mas o otimismo não pode cegar para a realidade. A organização tem capacidade de execução para atingir as espectativas?

4. A força de vendas foi treinada com base nas features do produto, e não em como o produto resolve o problema dos clientes. Bons vendedores vendem soluções para os clientes, não listas de funcionalidades, e portanto devem ser treinados para isso. Entenda como e por que seus compradores compram.

5. Esforço significativo é gasto na criação de material de apoio e ferramentas de venda que nunca serõa utilizadas, 90% do material de vendas nunca é lido pela equipe comercial, mas ainda assim as equipes de marketing gastam tempo com isso.

6. Não há uma pessoa responsável por direcionar os resultados do lançamento do produto. Deve haver um "launch owner" com responsabilidade sobre o lançamento.

7. O plano de lançamento é baseado em suposições, não em evidências do mercado.

8. Seu plano é cópia do plano de um concorrente. Nem tudo que vale para um player vale para os outros. Além disso, copiar o concorrente significa que você acha ele mais inteligente que você. Se você acha isso, que dirá o mercardo?

9. Clientes existentes não são considerados. Lembre-se da migração dos clientes atuais para o novo plano, não frustre os clientes atuais - é mais caro conquistar novos clientes do que manter e aumentar as vendas para os clientes antigos.

10. O time de lançamento de produtos não é um time. O time responsável deve ser matricial, envolvendo as diversas equipes vinculadas ao produto.

FONTE: TECNOLOGANDO

Entendendo o Usuário

2009-11-14T06:54:00.000-08:00

Uma das atividades básicas de todo Gerente de Produtos é entender as necessidades do seu ciente através de visitas e muitas conversas. É importante visitar os clientes por vários motivos:

entender quem é, de fato, seu público-alvo
entender as necessidades de seus clientes
como atender estas necessidades
qual design funciona melhor com este público

Assim, você poderá definir os usuários chaves (personas) que servirão de referência quando você estiver definindo os "detalhes" do produto (funcionalidades, design/experiência do usuário, preço, marketing/promoção, etc).

Dentre os vários momentos em que o Gerente de Produtos deve visitar e conversar com seus clientes, cito:

1) Durante a fase de definição do produto: qual produto fazer? qual o público-alvo? quem são os compradores? quem são os usuários? há mercado? as pessoas pagariam por isto? como usuariam?

2) Durante a fase de prototipação: como deve ser o layout do sistema? como devem estar dispostas as informações na tela? e os botões? quais são os termos mais adequados? como as opções dos menus devem estar agrupadas?

3) Durante a fase de lançamento: os potenciais clientes ficaram sabendo do lançamento do produto? a estratégia de marketing foi correta? os primeiros clientes gostaram? estão usando de fato? tudo que foi definido nas fases anteriores está confirmado?

4) Sempre: quais funcionalidades precisam ser incluídas? quais funcionalidades podem ser retiradas ou simplificadas? há usos do seu produto que você não havia previsto, mas que os clientes estão usando e valeria a pena você se adaptar? o suporte técnico está bom? há concorrentes alcançando seu produto?

Enfim, o Gerente de Produtos deve sempre saber como, por que, quando os clientes e usuários utilizam seu produto (ou não!) para mantê-lo útil e acessível para os clientes, e vendável / lucrativo para a empresa!

FONTE: TECNOLOGANDO