Why Word of Mouth Matters to You

by: stacey - January 11th, 2012   Filed under: Product Management Add Comment

Greg Stielstra over at Pyromarketing noted in this article that an eMarketer study on the greatest influence on buyer decisions, and word of mouth, that is, the recommendation of others, came through as far and away the greatest influencer on buyer decisions.  Word of Mouth is cited as being nearly twice as effective as the next closest influencer.  According to the Church of the Customer blog article  here- Word of Mouth is by far number one.

So why does this matter to you?  “I’m not in sales and marketing,” you say.  It matters to you if you have a job anywhere, doing anything- or even if you don’t.

Word of Mouth spreads people’s opinion of you.  It spreads their opinion of the work you do, of your team, of your project, of your department, your company… it goes on and on.  Looking for a job?  If your friends and past coworkers do not respect you and your work, you won’t be getting help from them- even if they say that they are helping.  Networking has been shown to be one of the #1 ways of landing a new job, and if you haven’t painted a picture of yourself positively with those who know you, you’ve cut yourself off from that market- or worse, turned it against you.

How about your next review?  Expecting a raise?  Do you think that if you have a poor image with your coworkers or customers that’s going to help you?

Funding for your project?  If the buzz around the company water cooler is that project X is hot, but no one’s heard much about yours, you might be in trouble.  Funding for more staff for your department?  Not if word of mouth says your department isn’t contributing value.

You should care about your reputation no matter what you do for a living.  Even garbage collectors have bosses who have to listen to complaints- and who hear praise.  What they say about reputations is true, too- they take years to build sometimes, but they come apart in seconds.  People are more likely to talk about negative things because they like to complain.  If you are consistently bad, everyone will know.  People talk about inconsistencies because they notice them.  If you do a good job normally, but make a screwup, they’ll notice that (of course, if you handle your error well, they’ll talk about that- which can do you good).  Most of all, people love to talk about their problems- so if you cause people problems, expect the word to spread.

On the contrary, integrity is admired.  Help is appreciated.  Value your working relationships with others and try to bring value.  Act with integrity and be fair.  Strive to be not just ‘a good employee’, but the kind of person people want to work with.  You can’t afford not to.

Tags:

Are You Ready to Upgrade?

by: stacey - December 29th, 2011   Filed under: Planning, Product Management, Project Management Add Comment

Most of us who have ever been involved in implementing a piece of enterprise software has faced this. You gather requirements and evaluate software vendors. You jump various political hurdles inside your company. You build your implementation team and start ramping up to install the product. In this middle of all of this, blammo! The vendor changes upgrades their product. Sometimes the upgrade is no big deal; sometimes it’s radical- like they rewrote it as a web application, or the app that used to be in powerbuilder is not written in c# or java. No big deal because you planned for that to happen, right? Uh, right?

For most companies, the answer is wrong. When evaluating vendors, never forget to do some basic homework on their future roadmap, how it will affect your project, and how their roadmap matches up to your plan.

Here’s some things to do to prepare for major version changes during your implementation:

1) Managing the version change within your project plan and scope
If there is a version change or other major product upgrade in their roadmap, be sure that you put that in your project plan. Make sure that you put time in your project plan to evaluate the new product and adjust the project plan according to the requirements of the new product. You doubtlessly will have to upgrade to the new version to achieve support from the vendor at some point; it’s easier to change now than after you’ve gone to production with the product. Treat this essentially as a major change request would be treated, only you have the bonus that you know when it will (probably) be and can schedule this in your project. If you are tempted to put it off until after you go live, don’t. This is like all other major project changes. The later it happens in your project, the more money and resources it will take to implement.

2) Managing the version change and having the right resources
Do you have the right resources available for the new version? If the code base changes in the new version, you’ll need programmers and techies versed in that code base. You’ll need systems architects available when you evaluate the new version of the product so that you can determine if the new version requires more and/or different hardware. You will probably need a business analyst to look at the new features in the next version to consider how the way the product will be used by the company may change and improve. You may need testing folks to change their testing plans, if any are already written, and you will likely need your trainers to adjust any material they’ve done up to now.

3) Managing your resources before the version change
Do not make the mistake of doing work for the sake of having people work before the change in versions come down. There will be a lot of work that can be done beforehand. There will be some work that may become obselete with the new version as well. Evaluate your task list carefully. Don’t waste time sitting around waiting for the new version, but don’t waste resources working on things that will be rendered obselete either. It’s a careful tightrope to walk.

Last but not least, never forget to document, document, document. Keep up with your vendor’s version upgrade schedule. You will have to upgrade the product again after it is in production. This is a learning experience as to how to do that. Save as much lessons learned and project plan material as possible from your upgrade so that you can make your future transitions more smooth.

Vendor products change. This is a reality of their business model. Plan for the change so it can fit within your business model.

Tags: , ,

Paying Down Debt

by: stacey - December 14th, 2011   Filed under: Management, Product Management Add Comment

In our current times, there’s a lot of focus on cutting IT costs.  Many leaders are challenged with proving the value of their budgets, their staffing, and even themselves.  A lot of people are running scared in the face of this.  They are putting pressure on their teams to build more, to add more features, to create more ‘value’ for the company’s dollar.

Consider this approach for a moment in the light of the concept of technical debt.  Technical debt is to your IT workforce what credit cards are to your kid in college.  Increased features and new products mean more maintenance costs.  Increased speed to market means increased bugs.  Rising technical debt means that your team will be able to contribute even less in the mid-term and long run.  Contributing new, buggy things rather than increasing the value of what you have simply lowers your perceived value to the business.

Before deciding to add new projects, products or features, ask yourself this:  is it time instead to pay down existing technical debt?  What can I do to lower support costs?  How much better can I make what I have?  Do I have any open requests from the business to solve old problems?  Can I increase my perceived value by simply focusing on lowering overhead and getting rid of ‘old’ problems that have been lingering?  Turning your efforts inward to improve now will give you a stronger position in the mid-term and long-term.  You will have lower maintenance later when you ramp up new projects, and by clearing your backlog, you’ll be surprised at how much support you will garner from your business partners.

Tags: ,