Showing posts with label Customer Service. Show all posts
Showing posts with label Customer Service. Show all posts

Tuesday, June 12, 2012

My Cure for Overambitious Projects

You’ve probably encountered clients that request an unrealistic amount of features to be included in a product. They’ll start by listing a few features that the product “absolutely must have,” which suddenly reminds them of a few more features, which then brings up more that “we probably should include.”

Meanwhile, your headache is growing because you know that such lofty expectations always fail.

Well, it’s time like this, before any of the development begins, that you’d benefit from splitting up feature requirements into two categories: essential and supplementary.

This simple action will save you enormous stress later on in the development process, because it forces both you and the client to agree on what is most important, and what can wait.

After you make the list, give a copy to your client, and keep one for yourself. Whenever an issue about including more features comes up, refer to the list and ask, “Is this truly necessary?”

-Judi

Some More Comments on Overambitious Projects

I previously asked readers to share their experiences with overambitious projects. Here were some of the replies:

Creative people always desire to create a perfect product. And it is very difficult to stop perfecting it… It’s not easy to differentiate between essential and supplementary features.

Also interesting fact from the “big science” molecular biology – the Human Genome project (that was also saturated with computation and programming). Finishing sequencing took as much time as the first 90% of sequencing work.

So true. There's an understandable amount of pride that creatives and entrepreneurs feel about their work--sometimes to their detriment.

And also this suggestion on how to handle feature-hungry clients

As a product manager, I have dealt with this issue many times.  It always helps to ask the client (internal or external) to estimate the additional sales that will occur if the new feature is added.  Invariably they either realize the answer is zero, or understand they have no way to credibly answer. No additional sales, no money for development. Simple but effective.

What a fantastic idea. It lets the client clearly see the value of each additional requirement.

-Judi

Friday, September 9, 2011

Build or Buy? How to know if you need custom software

I met a woman yesterday who asked me if we could build some software for her business. I told her yes, we could, but it probably wouldn’t make sense. Let me explain.

Building custom software is an investment, and that investment usually doesn’t make sense unless you’re going to sell multiple copies of the software, or it’s going to give you a significant competitive advantage in your business. And I do mean significant.

For example, I spoke with a company not too long ago that was thinking about developing some software to help them with an internal business process. They had done their research, and there were packages on the market, but they didn’t exactly meet their needs. I spent enough time with them to give them a ball park quote, and it turns out the custom solution was seven times more expensive than the off-the-shelf solution. Frankly, this isn’t even a lot. Think about it – if the vender of the generic solution spent the same amount of money developing their solution, they would only need to sell seven copies to break even. I realize it’s more complicated than this, there’s distribution, support, marketing, overhead, etc. but what if they sold 70 copies? You can see how this kind of investment could pay off. And if they sold 700 – wow!

So this company decided to buy the off-the-shelf product that met most of their needs. In my opinion, that was the right decision. It only makes sense to build custom software for internal use when you can get a significant competitive advantage. Before you think about investing in custom software, look at what’s already on the market to meet your needs. It may not meet all of your needs, or meet them perfectly, but ask yourself how much would it be worth to have that perfect solution? Would I be willing to pay ten times the cost of this package? More? Often the answer will be no, and in that case, just find the product that meets your needs the best or allows you some ability to customize.

Thursday, July 21, 2011

What it Takes to be a Successful Consultant

I have not written for a while on what it takes to be a successful consultant, but lately I’ve been noticing some common trends with our best people, and oddly enough it has absolutely nothing to do with their technical abilities. I’m really not sure what to call it – grace, poise, or just plain old fashioned professionalism.

In one instance, one of our clients handled an HR problem, let’s just say, in a less than optimal fashion. Our consultants there were affected by this decision, and one of them could have been justified to be hurt or angry, but to his credit, he just continued to do his job while the storm raged around him. He happened to be in our office one day while this was going on and his comment to me was “I have a job to do, and I’m going to focus on that and do my best.” Love that!!

In the second instance one of our consultants was working with an engineer at our client’s client on an integration project. I’ll spare you the gory details but this engineer was engaging in programming practices that would make any professional programmer shudder with disgust. The stories even made me shudder and I haven’t been a programmer in ages! To his credit, our guy worked thru the issues with this engineer without issue.

Although they’re all sharp, in fact some of the smartest people I know, I think I admire the restraint, respect and professionalism our consultants exhibit even more than their technical chops. We serve at the request of our clients, and being difficult or disrespectful does nothing for our relationships. I’m so proud to be a part of this team, with these amazing engineers and developers!

Thursday, November 18, 2010

When you’re done with product development

….you’re not really done. Let me explain what I mean.


We meet with lots of people and companies that would like us to develop products for and with them. They are sometimes under the impression that when we’re done creating the product, they won’t need any technical, engineering, or software development. After all, that phase is done, right? Well, yes, but the next phase is just beginning, and faltering here can be deadly to your product’s success.


Even if your product works perfectly, customers are going to have questions. Some sort of support will be needed. Not planning for this can be fatal to your product’s success. Often times, customers will be highly engaged and wanting more features and add-ons, creating opportunities and the need for enhancements. Ideally, more customers will want your product – maybe from an adjacent market or with needs not exactly targeted by your product, perhaps creating a need for other products.


All of these scenarios require additional support and/or continued development. Hopefully your product will be so successful, you’ll never be done!

Thursday, August 12, 2010

How to tell your customers they’re wrong

We often find ourselves telling our clients they’re wrong. Of course, we don’t say it like that – “You’re Wrong! Mr. Client!” No.


Sometimes they have a problem and already have a solution in mind. Our engineers can often tell very quickly their solution is not going to fix their problem. These discussions are usually easy. The engineers can come up with better solutions and it’s obvious we’re working in our customers’ best interests.


But what if you think they’re solving the wrong problem? This is a much more difficult conversation. Especially, if they are passionate about solving a problem that you don’t think is a problem. Maybe you’re not the one having this problem, but other’s are. Maybe they’d appreciate the solution. Who’s to know?


I heard a great suggestion on how to handle this just the other day (Thanks CS!). I love it because it’s open, and honest, and all about starting the relationship off right. Just ask – at the beginning of the relationship, or conversation, or wherever you happen to find yourself, just ask if they’re open to questions about their assumptions if you hear something that does not make sense. It might sound something like this “You know, Mr. Customer, sometimes I’m talking with other CEOs and they say things that just don’t make sense, they find it very helpful when I question these statements. Is that something you would find valuable?” I’d be shocked to get a no, but whether they say yes, or no, at least you know where you stand. And who know, you may just learn something.

Monday, May 10, 2010

Proposal Writing: What Do Clients Really Want? (Learning from our Failures)

OK, “failure” is kind of a strong word in this case. But here’s the story: We recently had the opportunity to do a “post mortem” kind of meeting on a deal we didn’t get (hey, you can’t win them all, right?) We thought we knew why, or had some ideas at least, but we wanted to find out for sure.


The client was generous enough to give us an hour of his time, and honest enough to give us really candid and open feedback. So what did we learn? Some of the things we had assumed were true, but there were others. The one that resonated most for me is the Business version of the grammar school advice to “Show your work”.


Our team had spent hours discussing this project, formulating an approach, and really drilling down into the details. In an effort (and it did take some effort) to make a clear proposal, we eliminated all the details behind our recommendations. Unfortunately the client interpreted that as a lack of analysis, and why not – he didn’t see it, so in his world it didn’t exist.


This really hit home for me. I was always a proponent of the short, sweet, clear proposal. I don’t’ know about others but I typically don’t want to read 20 pages of what someone thinks, but (ha – fortunately :-) ) not everyone is like me. Looking back it seems obvious that we should have included all the “sausage making details”, perhaps as an appendix or perhaps in the main proposal with an executive summary. I’m curious, what do others do?

Tuesday, May 20, 2008

Can Customer Service be Dangerous?

What lengths have you gone to, to handle or avert a potential customer issue?

I had my doubts about whether or not to tell this story, but my partner convinced me Michael - you're paying my ticket, if I get one.

I was running some errands today at lunch, and while stuck at a light I checked my Blackberry. I suppose I could tell you that this was the only time I'd ever looked at my BBerry while driving, but would anyone really believe me?

Anyway, I had just gotten an email from a consultant that was not going to be able to make a 1:00 meeting with a client. This was about 12:30. I did not have the client's number on me, and I knew I would not be back in the office before 1, so I called my office (also illegal to do while driving in CT) and was able to get someone to call the client to let him know. Issue averted!

Believe me - I get how dangerous this is, but I'm sure glad I was able to let the client know in advance. Don't try this at home.

Thursday, April 3, 2008

Full Process Review or Quick Fix?

Lately we seem to have so many consultants interviewing for so many opportunities it's hard to keep track of all the details. We do have some tools in place but they're not enough. When the "pain" gets to be too much we've been creating quick fixes to relive the particular difficulty we're having at the moment.

In a casual hallway conversation, we were just about to do this again, when it dawned on me that we had not really looked at our end-to-end process and inter-relationships between Sales and Consultant Services in a while. Certainly not since our business volume has picked up. My Software Development background kicked in and I suggested we take a step back and do just that.

I know that when we're moving so fast, it can be tempting to just address the immediate issue, but sometime a more holistic approach is the way to go. The trick is in knowing the difference. I think, just like in Software Development too many quick fixed can create a mess really quickly. In this case, we had been doing the quick fix thing for a while and it just seemed like time to look at the big picture.