Hello, this is Laura Lee Rose – and I enjoyed our Art of War for Product Managers and High-Performing Professionals.

Below is an abridged list of Q&A that I collected during that presentation.

Feel free to contact me at LauraRose@RoseCoaching.info for any follow-up questions or presentations.

Q: What does “never compromise with honesty” mean?

This means to keep the “real reason” for the task in mind at all times.  Don’t use the singular focus on numbers and dates distract you from the real reason for all your hard work.

For instance, even though your task is to get this product out the door on a certain date, the real-reason of the task is to release a high-quality product that customers will actually use.  The team was running late and the delivery schedule was in jeopardy.  To bring in the schedule, the product managers moved all the customer-review of the early design phases.  They also compressed the time between the Beta Release and the general release.  By by-passing usability studies, focus group prototypes and taking early demos to various trade-shows in order to save time; the product managers actually lost the opportunity to make sure the product will actually be used by the clients.   At the Beta Release, it was discovered that the customers like the idea of the product, but the implementation was not how they actually do their work.  The idea behind the tool was to assist clients to get their work done more efficiently.  This product was making the customer to fit the product instead of the other way around.  The team had to go back to the drawing board and the company cancelled the product release.

Another example: You know what the executives want to hear, so you put a slight spin on your status report to avoid conflict and disapproval.  You didn’t tell “a lie” – you merely didn’t tell the entire truth.  Your solution is for the team to just work longer and harder to catch up.  This strategy doesn’t work because the team is already working longer and was burnt-out.  The issues got worst and not better.

Another example:  The quality reason for retesting all the defects by a certain date is to allow the development team enough time to find, fix and retest the defects found by more testing.  In software development, any code change generates a 10% chance of creating or finding new defects.  By enforcing multiple deadlines in the product schedule to have all the teams retest all the accumulated ‘fixed items’ in their queue – allows those hidden defects to become visible with enough time to fix and retest.  A test group allowed their retest queue to get out of hand.  The 0 defect deadline was the next day and they realized that they would not be able to retest their 100 fixed items.  Since the developers said these items were fixed and the testers didn’t want to be called out on their defect counts, the testers closed all their defects without testing.  The consequence was that a significant number of defects were left in the product, the product quality suffered, customer complaints rose, technical support hour’s increase, and a costly emergency maintenance release was schedule.

Another example: In an interview, you’re trying to figure out what the interviewer (or your executives) wants to hear, instead of expressing who you really are (or the true status of the product).  Although you want to stay focused on answering the exact question that the interviewer is asking, don’t try to figure out what answer they are hoping to hear.  They need to hear who you really are (and visa-versa).  Answer as honest as makes sense – and don’t try to mind-read.  After you have answered, ask them how they would have handled the situation.  Then you can better comment on the way they handled the situation.  Many situational and scenario-based interviews have really no right or wrong answers.  By feeling comfortable finding out more about how their organization works, you can decide if this organization is a good fit for you….(versus spending a lot of time force-fitting the partnership).

I go into the: who, what, where, when and how in the IT Professional Development Toolkit.

Q: Who can you use as accountability partners in the professional realm?

Your manager, mentors, coaches, HR representatives and even clients can be used as both accountability partners and reasonable forcing functions.

You can use Reasonable Forcing Functions and Accountability Partners in your performance goals as well as your product goals.  In this discussion, we are not only focusing on your company “product” work but the work that you do on your product or “YOU, Inc”.  We all do well when we make external commitments to others at work.  But we may fall short to the commitments and tasks that we have only ourselves as the audience.  Incorporate the reasonable forcing functions and accountability partners in these tasks as well.

Sample of how to use an accountability partner: Tell a coworker, manager, mentor or coach about your individual career goals, your deadlines and milestones for certain individual projects, and status/progress.  Document these goals in your personal business commitment and individual development documents (signed by your manager).  Make your manager, mentors and coaches your co-conspirators in your career success. If they know where you want to go, they can keep an eye and ear out for you.  .  They can see, hear and go places that you don’t have time or access. You have now made them your secret agent and have increased your spying ability

Sample of how to use a Reasonable Forcing Function: One of your committed goals is to be better exposed to client perspective, bring in new business and to become known as an expert in this field.  You know that attending a technical conference will provide you the opportunity to talk to prospective clients, bring in some new customer leads, and learn more about your field of expertise.   Your company doesn’t have the funds to give everyone a trip to technical conference, but if you are selected as a speaker at a conference – they will send you.  A reasonable forcing function is to commit to submit 3-5 abstracts to the various technical conferences (they all have submission deadlines).  You get the approved list of technical conferences and start submitting 3-5 abstracts to each conference.  If you submit enough abstracts to various conferences, one of your abstracts will get accepted by one of the conferences.  You don’t have to have submitted the paper or outline until one gets accepted, so you aren’t spending time on the presentation until one is selected. Now that the abstract is selected – you have a reasonable forcing function to achieve your other goals.

Reasonable Forcing Function IS NOT a term from Sun Tzu’s Art of War book.  Rather is it a time management technique.  You all do it today in your normal life.  For instance, you tell your children that you can’t watch TV until your homework is done.  Your home is a wreck but you can’t seem to get motivated to clean it up; so you invite people over for next Friday night.  That forces you to make the house more presentable.  You love to paint and sculpt but you don’t seem to make time for it.  So you sign-up and pay for a sculpting class every Wednesday night.  You actually already do this.  We’ll just use it more deliberately and liberally.

I talk more about reasonable forcing functions and accountability partners in the professional development toolkit.
Q: Question regarding the comment that only 36% of a product is used by the end-user:

The Usage of coded features data was presented by the Standish Group at the XP Conference

 
Q: Being overwhelmed on the number of products you are to develop?  Here are some suggestions:

Recommend that you take more of an ownership of your own calendar, schedule and profession.  You are the one accepting those tasks.  Remember that all MUST DO products will get done, but they don’t have to be done by you.  Anything that doesn’t get funded or resources are simply not a MUST DO (by definition).  If it’s important enough, they will find someone to do it.  It is the executives role to properly fund and sponsor the things that really matter.

You are a great product manager, therefore – Product Manage – yourself.  Companies and managers are much like blind waiters.  They will continue to pour until YOU say “when”.  It is your responsibility to review the priorities, ROI, and which products are most in line with the company’s vision and mission statement.  Companies are in the business of making money.  High performing product managers can quickly determine which product will bring in the money and which are not.  Excel in putting your time and effort in high-revenue products and recommending end-of-life to those that are not making the build.  In today’s market, technology is changing so rapidly that if you continue to put effort in a product that’s just not cutting it; the chances are high that when it finally does make it to market, it will already be obsolete.  Don’t fall in love with the product, just because you’re assigned to it.  Always, look at your products objectively.  Not all products deserve to be released.  And the quicker you can pull the plug on the duds, the more money you are saving your company as well as effort on yourself.
Q: What’s the best way to handle overwhelment?

Transparency and communication is key to smoother releases.  Managers and executives often don’t care who does what.  They care about the important things getting done. If you continue to blindly accept projects and tasks (merely because people are handing them to you), then you run the risk of not delivering any quality products at all.  I always recommend frequent and regular one-on-one meetings (at least twice a month), with your manager.  If you only speak with your manager when something is wrong or during your performance review, then you are always anxious. If you regularly have these meeting (already scheduled in your calendar) – you are well-practiced in these meetings; your manager will be well-informed and you will know exactly where you stand (in performance metrics) at all time.

Your manager is responsible for handling and properly distributing the workload so that it gets done properly.  If you are honest with your status and realistic with your own time-management and project management schedule, he has the opportunity to re-assign before it’s too late.  By keeping it to yourself, you are tying your managers’ hands because he is unable to properly manage the situation after the train leaves the station.

ALSO – In these global and distributed times, it’s important to have a Communication Plan for various issues.  Some people only communicate via text, some folks only via phone, some people only do email, some people are on different and conflicting time zones.  By outlining your significant stakeholder’s communication preferences (time zones and contact information), you can be assured to get their attention when you need them.  Remember the real-reason for contacting them isn’t to just cross-off the item “send this information to xxx”.  The real-reason for contacting them is to make sure they receive the information, understand it and discuss the consequences.  Sending a quick email to check off “I sent him the information so I have done my part” doesn’t accomplish your real goal.

Having a communication plan and structure for your significant stakeholders will grease the wheels of communications.  For instance, you and your stakeholder may decide to:

1)     Merely update the internet wiki with regular status information and have an auto-responder that automatically email the link to the stakeholders weekly.

2)     Send an email with the subject header convention:  CALL TO ACTION xxxxx DUE yyyy  for requests or action items

3)     Call or text when a high-priority problem is encountered (and be armed with options and alternative solutions).  And setup a follow-up phone or in-person meeting for a longer discussion – keeping time zones in consideration.

4)     Person to person meeting or phone meeting for mentoring and coaching meetings.

5)     Frequent one-on-one meetings with managers on all status, future plans, business strategies and performance discussions.

I talk more about communication plans, one-on-one meetings, and performance evaluation strategies in the IT Professional Development Toolkit.

Q: Any tips for getting buy in from higher ups when trying to block out time?

It’s been my experience that ‘higher-ups’ don’t really have that much interest in your individual calendar.  You are the one in total control of your calendar.  You are totally responsible for your own career and professional development.  Expecting others to somehow make the time or allocate money for your individual professional and career development is a limiting state of mind.  You are the most influential person TO YOU.  You are the only one that can make a change in yourself.  It’s more empowering to acknowledge that it’s your responsibility.  You should certainly appreciate any and all support that you do get from your company.  But – in my opinion – you are not entitled to this from your company.  The company is in business to make money.  If it’s worthwhile (business wise) to invest in your professional career – the company will do it.  And it’s really, really nice if they help you in your career.  And you should really appreciate it.  But it’s really not their responsibility.  The more you can illustrate that it’s to their advantage to assist you (by aligning your career development to the company’s vision or bottom line), the better it will be for you.  But it’s really up to you.   I talk more about taking more ownership in designing your own professional career in the IT Development Toolkit. 

Therefore, – simply start blocking out time for your career development (10 minutes a day is a good start). Make your best judgment on what’s the best time to block out time. (For instance, if you know that your team has a weekly staff meeting on Monday’s at 2:00pm – avoid that time-slot for your blocked time). Tell people in advance that you have a standing meeting at that time.  Publish your calendar (with the blocked time clearly visible).  Use the ‘Do NOT Disturb’ functions during that time.  Send an authorized representative to meetings that you don’t feel that you really need to be there.  Make liberal use of the meeting notes and other meetings to stay on top of things.  Train and mentor others to attend selected meetings (and certain tasks) that both help them in their careers as well as off-load you with your time.   Use the 4 Ds (delete, delegate, diminish, and delay) from my IT Professional Development Toolkit series) to block and get more time.

Q: How does this work in an interrupt-driven company?

In interrupt driven companies – the idea is NOT TO COMMIT to many things and incorporate buffers between tasks to accommodate for this environment. In my IT Professional Development Toolkit – I talk about this as well.  If you know that your company is interrupt-driven – then you can project manage it appropriately.  You know you will be constantly interrupted so you don’t commit to many items.  You use my Sprint and Buffer method that is designed specifically for interrupt-driven environments.

I show the: who, what, where, when, why and how in the IT Professional Development Toolkit.

Q: Shouldn’t I wait for the company to define what a “good product manager” means?:

I disagree on making your company responsible for creating your definition of what makes a good product manager – to you.   You should incorporate their definition into yours.  But you are empowered to define who you really want to be.  If you have chosen the Product Management field, you should have your own definition of what it means to you.  It should exceed the definition of the company and fit your individual principles and goals.  Why make others responsible for defining who you really want to be?
What if two product manager colleagues disagree on something and can only agree to disagree and cannot come to a resolution, what do you do afterwards?

One recommendation is to find the common-shared goal among the three product manager.  Continue to bring the discussion to a higher-level until you get some type of agreement.  Oftentimes people are arguing over a detail or specific solution.  When people of like-minds and professions are arguing – it simply means that they are talking ‘at’ the wrong level.  It’s merely an indicator that the parties are looking in the wrong place for the answer.  When you pop-up the discussion to the next higher level, things tend to work out.

One example:   One product manager (Product Manager 1) states that this release needs to have a Drag-n-Drop feature in this release.  The other product manager (Product Manager 2)  is adamant that it cannot be included in this release because the code is from a 3^rd-party company.  There simply isn’t enough time to get the legal authorization to change it on our own, or get the 3^rd-party folks to change it.  Product Manager 1 knows that a high-profile client will leave the company and product – if we don’t but this feature in this release.

This is what I did:

1)     Paraphrased our common product goal:  Release the product with high-quality, on-time and with significant enhancements that clients will be very pleased with.

2)     Get everyone agreeing to the high-level common goal.  Get everyone on the same page with the company vision and mission.

3)     Try to kick-up the discussion by understanding “why” this change is needed in the first place.  I asked the team ‘why’ this change is needed.   Product Manager 1 says – “The client needs create a project plan from some of his other project folders.  He doesn’t want to start from scratch.  He wants to drag-n-drop his selected folders to create the new project.  He doesn’t want to re-invent”

4)     I paraphrased, “So, let me restate to make sure I understand.  You’re focusing on what the client really wants, which is what we all want.  And what the client wants is a method to import files from a previous project into his new project file.  He doesn’t want to start from scratch.  He wants an import function.”  (First understand and then be understood — from Steven Covey’s 7 Habits of Highly Effective People).

Product Manager 1 – “Yes – they want an import function”

I asked Product Manager 2: “I think we already have an import function, don’t we?  It’s not using the drag-n-drop feature.  But it accomplishes the essence of the goal.  It gets the job done, doesn’t it?”

Product Manager 2 nods, “YES – it’s called IMPORT.  You can browse your directory and click on the folders to drill down.  You can even drill down to the documents and specific lines to import.  Once you have highlighted the areas that you want imported, you just hit the IMPORT button.  You can even include everything and then mask-out things you don’t want to include (which are a faster way to important large amounts of data).”

Product Manager 2 is happy, “Really?  That’s even better than what they asked for.”

Product Manager 1. “And it’s already in the product that they have today.  They don’t have to wait until the next release….”

The stale-mate was caused by getting too caught in the details.  Product Manager 1 wanted to give the customer what he/she was asking for; customer was asking for a specific solution (drag-n-drop) to answer their problem; Product Manager 2 was narrowly focused on the impossibility of that one solution (drag-n-drop).

By disengaging from the specific details on HOW something will be accomplished, and focusing on exactly what is trying to be accomplished – most people can find a common, shared goal.  I talk more about how to use paraphrasing, listening techniques, negotiating techniques and finding the common ground in the IT Professional Development Toolkit.

 
Q: Do you have a good business case and/or justification?  Where I work I can’t pull resources from other teams unless justified

This is a great use of the Recovery Protocol (detailed in the IT Professional Development Toolkit).  Every company is different.  Every product is different.  That is why you create a recovery protocol chart before your project is started.  If people agree to accept the fact that you cannot add resources, then that becomes the unyielding attribute.  The group now agrees that the other legs need to change:  scope of the product, the release date of the product and the quality of the product.  If your group decides that something else is NON-NEGOTIABLE or inflexible, then they have agreed that resources will change.  The key is to get this agreement upfront so that you are not wasting time during the fire.

Another suggestion is to be creative with your resource definitions.  I had a 10-3 developer to tester ratio.  The testers were not able to keep up with the output of the developers.  So I got creative with my resources and looked into areas that wanted to get early versions of the product.

1)     The documentation team needed early versions of the software.  They also needed customer scenarios for the features.  So I gave them all our test-case user-scenarios.  They were responsible for testing the user-case scenarios as well as using that as their foundation of their manuals.  They also created new test scenarios for our test cases and their manuals.

2)     Tech support needed to understand the new release, so they were happy to retest several of their customers reported defects on the software.  Even though the Tech Support team only focused on the defects their clients reported, this off-loaded the retesting that our testers needed to do.

3)     Sales teams needed to better understand the product and create demos for their trade shows.  We gave them test cases so that they can automate in their demo.  They ended up testing the software while they were creating their trade-show demos and presentations.

4)     Training team used and tested our test-case scenarios as part of developing their training materials.

5)     The usability and customer focus groups needed early versions of the product, so they became our early deployment labs of the product.  They tested the installation and configuration of the products in their usability labs.

6)     Developers were in heavy development mode in the early elaboration phases of the product, but testers were under-utilized because things were not ready to be functionally tested.  Testers were repositioned to help unit test with the developers.  This allowed the developers to see how the testers would be testing the product further down the line.  Testers also automated the developers unit tests – so that these tests became the build-release and acceptance tests.

7)     During the end-game, the developers’ loads were reduced (because their development cycles were coming to a end), they were then repositioned in system testing of the software.  Because the testers had helped the developers in their unit tests, the developers were happy to help.

This is another example of focusing on the wrong item.  If you allow having “NOT ENOUGH STAFF OR TESTERS TO TEST THE PRODICT” be your center, then you will not get the product out the door on time.  If you focus on the common team goal “GET THE PRODUCT PROPERLY TESTED” then you can design all sorts of other resources to accomplish the testing tasks.  Testing doesn’t have to be done by ‘testers’.  Testing can be done by anyone needing an early version of the product to get their individual task accomplished.

Q: I work for a company that deliver an education platform, so talking to students and faculty are not easy so much of the direction we get are from the university business folks…How do you balance on what the student/faculty may need vs what the business (registrar, student services, etc) think they need?

You can create an end-user focus group that includes students by offering to go into the University to work with the students.   If you couch your interest as “I want to make sure we are providing exactly what you and your students need….” the university would not see a problem with these types of visits. In my Design Partner Program, I regularly setup interviews and visits with the end-users (versus the buyer).

I often went into my clients’ software labs to see exactly how they were using the product. I tagged along with the technical support and deployment teams when they were rolling out my product. Only issues I ever had been with government security issues; and even then, they arranged a lab that was acceptable for this usability study.  The clients immediately see and understand the Win/Win of this offer.

Q: My company has $0 budget for professional development, so I can’t really do this.

Once again, your professional development and career is not your company’s responsibility.  Therefore, why are you waiting for your company to invest and fund your success?  If you allocate a budget to hobbies, gyms and other interests – shouldn’t personal and professional development also be an important investment in yourself?  The IT Professional Development Toolkit is cheaper than most hobbies and gym memberships, and takes only 10 minutes a day.

In the toolkit, I outline how you can get your company to send you to training conferences, professional association fees, and industry magazines on their dime.  The key is to make it cost-effective for them do to so.  Setup an in-house training program that you facilitate.  Attend these professional events and bring the training back to the team; speak at the training-conference and professional organizations to illustrate that your company is a thought-leader in this space; bringing back sales leaders and meeting with prospective clients while you are at the conference; get your articles published in these technical journals, etc.  Bring something to the table to illustrate the company WIN..

Q: I can’t afford to block out the time for this.

The IT Professional Development Tools are designed to be studied and practiced in ten minute blocks (the size of a work-break).  If you have time for a 20 minute chat in the halls, you have time for a ten minute practice session.  Whether you invest in the toolkit or not, blocking and scheduling ten minutes a day on your career is a smart goal and commitment.  You can change your life in ten minutes a day.