web counter

Posts tagged as:

software development

The 5 Types of Beta Testing Programs and Why 4 of Them Suck

by The Cranky Product Manager on December 18, 2008

in Beta Testing

Let the Cranky Product Manager remind you all of the purpose of  Beta testing programs:  To get customers to actually use your about-to-be-released software.  Why? To find and fix problems that would not have been found by internal-only testing.

So WHY then, WHY(!?) do so many so-called Beta testing programs seem explicitly designed to PREVENT this type of feedback?

Let the Cranky Product Manager classify and explain the different types of Beta programs, of which the vast majority  do NOTHING to improve product quality or identify customer issues.

1. The “Don’t You Dare Complain Because This is Free” Beta

This type of Beta is otherwise known as the “Google Beta”.  An Example? Take Google Gmail, which put out its Beta release on April 1, 2004.  As of this writing in December 2008, 4.5 years later, Gmail is still officially in Beta, with no word for an official release. Ever. 
Clearly, the purpose of this type of Beta is NOT to collect customer feedback.  More likely, the “Beta” designation is a euphemism for “No Support. Take It Or Leave It. Don’t Complain To Us If It Doesn’t Work Because It’s Free.”
If there is no mechanism in place to actively contact Beta customers and solicit their feedback (as opposed to just relying on them to send messages to a forum or send YOU an email), and if there is no path to ever release this product, well it’s a “Don’t Complain Because It’s Free” Beta.

2. The Paper Beta

This is where a company has a ridiculously short Beta period, and as a result recruits very few (if any) test customers and thus gets very little feedback.  The whole goal here is to NOT uncover issues.  Instead it is to push a piece of crap out of the door on a certain date, regardless of (lack of) quality, while still being able to honestly look customers in the eye and tell them your product was Beta tested.  Because, yes, savvy customers ask that. 

(Even savvier customers ask how big the Beta program is, how many customers participated, how long it lasted, and how many issues were uncovered and subsequently fixed.)

Result?  There is no real effort to sincerely, honestly collect feedback.  And any feedback uncovered will probably be ignored – because “it’s too late to fix it now.” Bugs will be filed, and possibly, MAYBE, they’ll be addressed in the next production release.

If your Beta uncovers less than 10 issues or is less than 4 weeks long, congratulations, you had a Paper Beta.

WARNING: Running a Paper Beta will DOOM your efforts to recruit customers for any future Beta program – Paper or not. The few customers that do participate be incensed that they spent time installing, testing, and providing feedback on your software, only to have their issues summarily ignored and potentially never fixed.

3. The “Agile” Beta

Allergic to any form of process, some Agile proponents will claim their awesome methodology eliminates the need for expensive Beta programs.  Why? Because, supposedly, with Agile the product is “Beta every day,” or at least it is at the end of each sprint or iteration.  And part and parcel of the Agile philosophy is getting direct customer feedback throughout the entire development process. Ergo, the claim that no Beta Program is needed.

All this is fine and good, but it still does not obviate the need for a Beta program.  Because without getting actual product into the hands of actual customers, you won’t uncover the problems that can’t be uncovered in internal-only testing.  It is ESSENTIAL that the customer actually attempt to use the software ON THEIR OWN, for things THEY actually want to do. If they don’t and you just provide a demo or screenshots (as is often the case for Agile-style “in process” customer feedback), well TOO BAD it doesn’t count.

How did you get into this sad situation?  Most likely, it’s because you’re letting the Development organization push you around.  Because, after all, if the Beta program is eliminated, their jobs become easier and less work. Plus, they can now push their risky bug fixes to the very last minute – as in minutes before that “final build.”  This is extremely dangerous yet happens all too often. 

4. The Haphazard Beta

The Haphazard Beta is one where you get the product to a particular state, claim it’s Beta, and THEN try to figure out (last minute!) how to actually recruit some customers and get some usable feedback.   There’s no organization, and no directed attempt to collect and quantify feedback. 

It’s a mess. A big loosey-goosey, panicky mess. 

And it’s your fault, Product Manager. Your fault.

If you had been on the ball and actually done some recruiting ahead of time, along with a smidge of planning about how to collect and handle issues, well you might have actually had a REAL Beta. Alas, it’s too late to fix it all now. So hold on tight, pray you don’t lose your job, and promise to do better next time.

5. The Real Beta

This is the Beta program done right.  Real customers and prospects actually use the software and identify issues (at the bug level, workflow level, and higher levels) that you could not have found on your own. 

And THEN… here’s the kicker…. you actually DO something about the issues they find.  That is, YOU ACTUALLY MAKE CHANGES.  You fix the bugs.  You fix the work flows… You learn how to make your product better. 

And it all goes smoothly.

You have recruited enough customers – in both number and variety - to accurately represent your target market.  You have enough time to fix their issues.  You care enough about putting out a quality product that the final product is something that you can be proud of – something that won’t create a PR disaster requiring a zillion-dollar advertising Band-aid, like the well-known disaster below…

{ 22 comments }

Badness All Around

by The Cranky Product Manager on November 18, 2008

in The PM Profession

Badness abounds. 

Like many (most?) software companies, DysfunctoSoft is goin’ through some hard times. Q3 sales sucked and then that whole October-through-now financial meltdown thing happened.

So the axe fell. And as it often does, the head-cutting machete hit Product Management extraordinarily and disproportionately hard.

(Out of respect for fallen comrades, the Cranky Product Manager will not be making any of her signature lame attempts at humor in this here blog post.)

The Cranky Product Manager had to lay off one of her team members. This really sucked. Big Time. The guy was a really good PM – he was absolutely fantastic with the Sales team, although less so with Development.  But, alas, the Cranky Product Manager is also really good with Sales, and less so with Development. Thus, she needed to keep the dev-focused Product Managers instead.  

(Lesson: If your strengths and weaknesses are the same as your boss, your boss will adore you and “get” you, but might lay you off more readily.)

When the dust settled after DysfunctoSoft’s Week of Carnage, one third of the entire product management team was gone.  Much worse than Sales. Far better than IT.

All this badness got the Cranky Product Manager making lists and rating stuff.  She now presents her list of software company job functions, ordered from most likely to be canned in bad times to least likely.

MOST LIKELY TO BE LAID OFF IN A BAD ECONOMY

  1. Recruiting
  2. Internal Training
  3. IT
  4. Customer Support
  5. Documentation
  6. Product Management
  7. Marketing (PR, Corporate, Events, Website, Lead Generation, Analyst Relations, …)
  8. Product Marketing
  9. QA
  10. Professional Services
  11. Development
  12. Human Resources (need someone around to help cut those heads)
  13. Telesales / Inside Sales
  14. Investor Relations
  15. Sales Reps & Sales Engineering
  16. Finance (because the CFO wields the axe but spares his own team)
  17. Legal

LEAST LIKELY TO BE LAID OFF IN A BAD ECONOMY

Conclusion: Product Management is cut much too early and too deeply compared to other functions, especially when you take into account how critically important good product management is to the success of the company.  The Cranky PM is no finance expert, but she’s been told this is because PM often falls under the “R&D” cost bucket on the income statement, and thus competes with Engineering and QA for funds, even if Product Management does not report to Engineering and is in its own Products organization. In contrast,  Marketing falls under the usually much bigger and more fungible “SG&A” cost bucket.

Is this right? The Cranky Product Manager would appreciate any corrections or comments on this.

{ 16 comments }

WTF Refactoring

by The Cranky Product Manager on November 5, 2008

in Development

Scene: War Room. 2 days until Code Freeze.

LEAD DEVELOPER:
So, unfortunately, we’re going to have to pull FavoriteFeature out of the release in order to meet the schedule.

THE CRANKY PRODUCT MANAGER:
Huh? That feature’s been in the product for 3 releases now. Customers love it. Why do we have to pull it?

LEAD DEVELOPER:
Well, we had to refactor the code, but unfortunately we just don’t have the time to write unit tests.

THE CRANKY PRODUCT MANAGER:
Why do you need new unit tests? Can’t you just use the old ones?

LEAD DEVELOPER:
We can’t. We don’t have them.

THE CRANKY PRODUCT MANAGER:
Why?

LEAD DEVELOPER:
Because they weren’t working with the new code.

THE CRANKY PRODUCT MANAGER:
(pause)
Refactoring means cleaning up the code while preserving existing functionality, right?

LEAD DEVELOPER:
Yes…

THE CRANKY PRODUCT MANAGER:
(pause)
So, if we’re preserving existing functionality, why did all the old unit tests fail?

LEAD DEVELOPER:
Well, I, uh…. Well, …while the guys were in there modifying, you know, the CODE, well, they, uh, figured they could, uh…, well…, add some stuff to create some WICKED cool Hologram broadcasting stuff. It affected the old tests.

THE CRANKY PRODUCT MANAGER:
(pause)
First, Hologram what? That’s not in the backlog!

LEAD DEVELOPER:
We thought it would be cool.

THE CRANKY PRODUCT MANAGER:
No one agreed to it or even discussed it! Seriously, dude, what the effing eff!?

LEAD DEVELOPER:
 (looks at his shoes)

THE CRANKY PRODUCT MANAGER:
Second, how can you look me in the eye and call this refactoring when you SO did NOT preserve existing functionality? The Cranky Product Manager calls BULLSHIT. You did a rewrite or rearchitecture or whatever, in a risky piece of code without telling anyone, and then you try to claim it’s a “refactor”. How the FRAK is the Cranky Product Manager ever to believe you again when you tell her you’re refactoring something for readability and ease of future maintenance?!? Do we need group reviews of your code on a daily basis to make sure you’re not slipping Warp Drive into the product?

LEAD DEVELOPER:
(looks at someone else’s feet)

THE CRANKY PRODUCT MANAGER:
Third, can you tell me what the POINT of even having unit tests IS, if all you do is DELETE them when they fail?

LEAD DEVELOPER:
(Looks at watch)

THE CRANKY PRODUCT MANAGER:
(Sweet smile)
And forgive me for pressing on this point, but you’ve said, and I quote, ‘John McCain will reform the way Wall Street does business….’  Can you give us any more examples of McCain’s leading the charge for more oversight? … Specific examples in his 26 years of pushing for more regulation?

LEAD DEVELOPER:
Well, I’ll try to find you some and I’ll bring them to ya!

CPM smiles genially, then slowly pulls every single last hair from her head.

{ 12 comments }

Caption Contest: The Clockwork Mouse (The Seven Types of Software Engineers)

by The Cranky Product Manager on October 29, 2008

in The 7 Types of Engineers

Reader Eric submitted this addendum to the original “The 6 Types of Software Engineer.” The Cranky Product Manager liked it so much, she changed the name of the series to “7 Types of Software Engineers.”

Submit captions for this cartoon of “The Clockwork Mouse” in this post’s comments. And don’t forget to submit captions for the other Software Engineer Types as well…

The Clockwork Mouse

Unlike the other types of software engineers, the Clockwork mouse is most often female. The Mouse works consistently, quietly, and diligently on any project, sub-project, or tiny little feature that is given to her. She is the perfect engineer for that boring file conversion job.

Distinguishing Characteristics

  • Rarely leaves the safe haven of the cube. Must be forced to join meetings.
  • People often ask how long the Clockwork Mouse has worked there when she is spotted (briefly) outside the confines of her cube. Very often, the Mouse has been with the company longer than the person asking.
  • Often talks with a very meek voice and is unwilling to contradict anybody, even when she clearly knows the right answer.
  • Nobody knows what this engineer does with her personal time.
  • Will consistently finish projects on time, but in the most bland manner as possible.
  • Her sense of interface design is non-existent. The interface will either be horribly complex and confusing or so primitive that it will make you wonder if if a C: prompt would be better.
  • She often codes something completely different from the specs because she is too afraid to ask questions.

Project Pitfalls
You may not know this engineer is actually on your project.

Achilles Heal
Any type of social interaction will cause so much stress that the Clockwork Mouse might blow a spring.

Best Bet
Assign non-interface related projects that are intricate, yet boring. The mouse will thrive in this environment. QA is another good bet.

Also in 7 Types of Engineers

  1. Caption Contest! (7 Types of Engineers)
  2. Caption Contest: The Veteran (The Seven Types of Software Engineers)
  3. Caption Contest: The Hotshot (The Seven Types of Software Engineers)
  4. Caption Contest: The Great One (The Seven Types of Software Engineers)
  5. Caption Contest: The Teflon-gineer (The Seven Types of Software Engineers)
  6. Caption Contest: Offshore (The Seven Types of Software Engineers)
  7. Caption Contest: The Maverick (The Seven Types of Software Engineers)
  8. Caption Contest: The Clockwork Mouse (The Seven Types of Software Engineers)
<< Previous in series |

{ 16 comments }

Caption Contest: The Teflon-gineer (The Seven Types of Software Engineers)

by The Cranky Product Manager on October 29, 2008

in The 7 Types of Engineers

Submit captions for this cartoon of “The Teflong-gineer” in this post’s comments.  And don’t forget to submit captions for the other Software Engineer Types as well…

The Teflon-gineer

The Teflon-gineer will do anything to reduce his work. If you’ve asked for a sports car, this engineer will try his/her damnedest to meet your requirements with a Model T Ford. Deflects all bug assignments with his/her Teflon Work Deflector (in size ‘J’ for Jerk).

Distinguishing Characteristics:

  • Says things like, “Are you sure the users really want that?” and “Is XYZ functionality really that important? How many users did you talk to? Can I see your notes?“
  • Reassigns his bugs back to you with updates like, “Please provide more clarity“, even when you’ve already referenced the spec page and section which spells out the original requirements with blinding clarity. When you reassign the bug back to him, you get his Out Of Office response.
  • Attempts to lock you into a legal contract specifying everything down to the last minimalist kilobyte of code that will be written.
  • During spec reviews or Scrum, says things like “Oh, you want the page to validate the user’s password entry? Well that will cost you an extra 2 days of work…plus another day if you want that alpha tested.“
  • Attempts to break your will to live with never-ending requests for excruciatingly documented detail to the point where it would be faster to code it yourself (inclusive of the time it would take you to learn Python).
  • When he delivers, his code is solidly mediocre. He never surprises, never innovates, and never has ideas.
  • Even his peers think he’s kind of a jerk.
  • Likes to watch When Animals Attack.

Project Pitfalls:
Serving your sentence for justifiable homicide will impede the project schedule.

Do you need this engineer?
Did you need your sibling to hold his finger one inch from your nose and say “I’m not touching you. I’m not touching you. I’m not touching you…“4

Achilles Heel:
His manager thinks he’s a jerk, too.

Best Bet:
Get this engineer off your project. Confront him/her, document as much of this crap as you can, then confront his manager. No good can come of this.

Also in 7 Types of Engineers

  1. Caption Contest! (7 Types of Engineers)
  2. Caption Contest: The Veteran (The Seven Types of Software Engineers)
  3. Caption Contest: The Hotshot (The Seven Types of Software Engineers)
  4. Caption Contest: The Great One (The Seven Types of Software Engineers)
  5. Caption Contest: The Teflon-gineer (The Seven Types of Software Engineers)
  6. Caption Contest: Offshore (The Seven Types of Software Engineers)
  7. Caption Contest: The Maverick (The Seven Types of Software Engineers)
  8. Caption Contest: The Clockwork Mouse (The Seven Types of Software Engineers)
<< Previous in series | | Next in series >>

{ 13 comments }

Customer Self Sabotage

by The Cranky Product Manager on October 23, 2008

in Customers

The Cranky Product Manager flew many miles, suffering through innumerable connections, delays, malnourishing food, and indignities heaped upon her by TSA officials. All to interview this fantastic new customer that just spent a huge wad of cash to buy DysfunctoCrank. Even better, this new customer represented a new and potentially very lucrative market segment. With a bit of product work, perhaps DysfunctoSoft could make Big New Customer blissfully happy plus have legions of new prospects beat a path to its door.

So the Cranky Product Manager had big plans. She was going to LEARN this customer, Ninja Style. All its sundry business problems. All its hopes and dreams. All its political quagmires.

She was going to LISTEN LISTEN LISTEN and identify those key use cases, capturing their very essence, and distilling them to succinct, beautiful user stories that were perfect in proportion and packed more punch than a Long Island Iced Tea.

The CPM would get to know those users better than their own mothers and spouses, and then — like Steinbeck, Hemmingway, and Shakespeare before her — she would create personas. But not just ANY persona. No, the Cranky Product Manager could never abide by that. Her personas would NOT be lousy one-dimensional cartoons, ala Joe the Plumber. Never! Instead,the CPM’s personas would be fully realized characters that spring to life on the page and burrow deep into the developers’ psyches — making those Code Boyz and Grrls not only better coders/artistes, but also more empathic, more grounded, and better people.

And so the Cranky Product Manager prepared. A lot. She made lists of questions and topics. Unearthed her voice recorder. Thought of fun games and exercises she could do with the customers. Practiced active listening and open-ended questioning with her Cranky Kid (“So tell me, Cranky Toddler, what do you think about Elmo? Does he help you? How? What is the value of Elmo completely solving this problem for you? How would you compare the value of Elmo’s help to Thomas the Tank Engine’s?”).

The Cranky PM got the Sales Droids to line up a full schedule of in-depth one-on-one interviews with representatives of all the main stakeholders. She even sent ahead her favorite handout on Persona interviewing, so the customer would understand why the CPM was asking such detailed questions about each user’s overall job responsibilities and motivations.

And then. Of course. It all got screwed up.

A simliar act of customer self-sabotageWhile the CPM was flying 40,000 feet above some square red state, a Veep on the customer side decided it was a big waste of time for “her people” to spend so much time meeting with the Cranky Product Manager. Instead of the six one-on-one interviews, the Veep decreed there be just one 60 minute meeting of the group. Never mind that everyone was still “wasting” the same amount of time, exactly 1 hour. No, that didn’t matter. Because the Veep’s whole point was about flexing her power over a software vendor, and NOT about being logical or rational.

As expected, the one hour group meeting did not go well.

Strike One: The room was overflowing with 30 people, 75% of whom were completely unfamiliar with the product and had no idea how they would ever use it. They were told there was going to be a product demo and food. But alas, neither was planned.

Strike Two: The Cranky Product Manager gave her introductory spiel about how important it was for her to understand Big New Customer’s actual business problems, all to ensure that future product changes lined up with their needs. Well, despite all the nodding heads in the room, the Veep laid down the law. “I don’t think we need to go into all that. Let’s stop wasting time. Your Tech Support already has the list of all the enhancements we need.” Great. Nothing like a list of enhancements with no context to guide product development.

Strike Three: The Veep insisted the Cranky Product Manager give a demo and then a roadmap presentation. Neither of which was originally planned. Fortunately, the CPM was always ready to give either at any moment. But damn if the roadmap preso wouldn’t have gone better if she had understood this customer’s problems better and was able to speak specifically to their pain.

And so the entire customer visit was (mostly) for naught. Despite the CPM’s attempts to turn the audience’s roadmap questions into learning opportunities (“You’re asking if we’ll have feature X. Is that important to you? Why?”), very little was learned. Not enough to create personas. Not enough to identify key use cases and write user stories. The best she got was a few business cards. Maybe she’d be able to contact these people for interviews later, but probably not since their Veep made it clear she thought their communicating with a vendor was wasteful.

Naturally, the tale ends woefully.

The next release was NOT what Big New Customer wanted, nor what they thought they outlined so clearly in that list of 37 enhancements submitted to Tech Support. The Cranky Product Manager had every intention of making major revs to the product to meet this customer’s needs, but instead Big New Customer sabotaged the Cranky Product Manager’s information gathering efforts, thereby unwittingly sabotaging themselves as well.

Stupid dumbass customer.

{ 5 comments }

Poll Results: Software Development Methodologies (Agile vs Waterfall)

by The Cranky Product Manager on October 10, 2008

in Agile/Scrum,Polls & Surveys

Big thanks to the 119 of you who deigned to answer to the Cranky Product Manager’s lil’ Facebook poll on software development methodologies. The poll is now closed.

While this is hardly a scientific poll, the results show a HUGE change in software development methodologies between now (2008) and two years ago (2006).

Software Product Development Methdologies: 2008 vs 2006

Software Product Development Methdologies: 2008 vs 2006

  • In 2006, you reported that a sizable majority of product development used a waterfall methodology (55%), with Scrum garnering a mere 7%.
  • In 2008, the picture is very different. Scrum and its Agile cousins account for nearly 60%, where waterfall has dropped to a mere 28%.
  • The percentage of products using waterfall dropped by 50% in just two years! (from 55% in 2006 to 28% in 2008.)
  • Scrum increased by 410% (!), and is now definitely the most popular flavor of Agile.

Wow. What a difference in just two years.,

Poll Conclusions

The CPM sees the writing on the wall. She’s now on a mission to learn all she can about Agile/Scrum in order to stay employable. But geez, there’s got to be something better out there than that canonical (naive) Scrum book. Something that reflects the realities of developing software PRODUCTS for multiple customers, not doing custom one-off developing projects. Please, say there is.

Nonetheless, the CPM thinks we are approaching Agile’s “Peak of Inflated Expectations,” soon to be followed by the “Trough of Disillusionment” (to borrow phraseology from the much-despised Gardeners), as people realize Agile still has flaws and is no Silver Bullet. Plus, Agile’s flaws aside, waterfall is not going away completely as there are too many products that CANNOT be developed via Agile (hardware, medical, defense, heavily regulated industries, products with very spread-out or outsourced development teams, to name a few).

Detailed Results

119 people responded to this Facebook poll, run between September 12 and October 1. Bare in mind that the readers of this blog are hardly representative of the entire software industry, and that the ones that use Facebook might be even less representative. Nonetheless, the results are very telling.

Question 1: Is your product currently being developed with one of the following software methodologies?

Reported Software Product Development Methodologies in 2008

Question 2: Two years ago, what methodology was used for the product from Question 1?

Reported Software Product Development Methodologies in 2006

Reported Software Product Development Methodologies two years ago, in 2006

{ 10 comments }

The Engineering VP Who Couldn’t “Get” Product Positioning

by The Cranky Product Manager on October 6, 2008

in Marketing

The Cranky Product Manager has taken up grinding her teeth once again.  It’s the frustration. From dealing with Development.  What is it this time?  Well, let the CPM explain.

The Cranky PM is sure that most of her product management brethren are familiar with that oft-cited formula for a product positioning statement:

For [target customer], who wants/needs [compelling reason to buy], the [product name] is a [product category] that provides [key benefits].

Unlike [main competitors], the [product name] [key product differentiation].

It should not surprise you that the Cranky Product Manager finds creating positioning statements to be VERY valuable. She’s a big fan. Because you can’t do everything and you need to focus. Because people are very different and thus their needs, wants, and priorities are varied. Because if your product doesn’t solve at least 80% of some customer’s problem, you probably shouldn’t even bother. This all seems obvious to her. It’s baked into her DNA.

So she asks for your suggestions please!  What should the Cranky Product do to the DysfunctoSoft Sr. VP of Engineering (whom the Cranky PM happens to report to) who objects to the first part of this formula — namely the practice of identifying the target customer?

Waterboarding?  Tacks on his chair? Club him on the head with Geoffrey Moore’s Crossing the Chasm book (the Cranky Product Manager’s all-time-favorite product management book, btw)?

Listen to the ramblings of the idiot:

Why should we limit ourselves to just those types of customers?  EVERYONE needs our stuff. Can we say “everyone” for our target?

Why do we have to have a target customer anyway?  Google didn’t have a target customer.(Actually, the CPM suspects they did, but whatev.)

Well, ok, if you really want me to narrow it down, how about we say ‘everyone with money’?  Or ‘users at large enterprises and SMBs located domestically and abroad’? Or ‘everyone who uses computers’?

If we limit ourselves, we’re in danger of leaving money on the table.  We’re going to take over the WORLD one day with our awesome technology — it will be as ubiquitous as water. So I think specifying a target market is dangerous and dumb. No one specified a target market for water, and look at how successful water is!

ARGGGH.  Seriously, these arguments are so nonsensical to the Cranky Product Manager she finds herself having difficulty even grasping them.  To her, they’re like answering the questions “Why do we have to EARN money with our software, anyway?” or maybe “Why do we want people to buy our software anyway?  It’ll send support costs through the roof!”

Please help.  Before the Cranky Product Manager is forced to get one of those saves-your-teeth-but-kills-your-marriage bite plate thingies.

{ 15 comments }

Following Up: Customer Advisory Groups

October 2, 2008

Following up on yesterday’s post on Customer Advisory Groups/Boards/Councils, you should realize that the Cranky Product Manager is hardly the definitive authority on the subject. So she thought she’d ask you all to contribute your wisdom. What are your thoughts on the effectiveness of Customer Advisory Groups? Any tips/tricks on how to get the most [...]

Read the full article →

On Customer Advisory Groups

September 30, 2008

Two questions from readers triggered this miraculous post: “What is your opinion of the effectiveness of Client Advisory Groups, and do you think that PMs (cranky or not) should organize and facilitate them?” “Follow up to the Client Advisory Groups, assuming you have an existing CAG how do extract useful feedback and integrate it with [...]

Read the full article →

← Previous Entries