So you want to be a VP?

I am periodically asked about becoming a VP.  That is the wrong question. An appropriate question is, "How do I increase my organizational, customer, or industry influence?" Recognize that our interests are not what drive other departments.  They want to execute and grow a business.  For them, technology is a means to an end.  To influence them, seek to understand their world.   

I recommend three groups with whom you develop relationships. 

Customers

Find ways to visit customers, attend customer events, or join calls with customers.  Set aside time to learn about your industry (in my case, healthcare).  The more you understand your customer's business and industry, the better partner you become.  It will improve your product decisions, as you will have context for how your customers use your product and the problems they are trying to solve.

Business partners

Your business partners include departments like sales, support, services, and marketing.  Take time to learn how they do what they do.  For example, learn how a salesperson gets quota credit (you do know what quota credit is, right?) or when and how your services team recognizes revenue (you do know what revenue is, right?)  Once you learn these concepts, you will have a better appreciation for why June 30 is significantly more than one business day away from July 1.

 

Finance and accounting

Learn how the money works in your organization.  There are critical concepts like capitalization, R&D Tax Credits, and so on that impact your company financial statements.  These in turn impact your ability to hire or to buy software. Financial management is as much a software development executive function as is shaping engineering practices and technology choices. 

I have never met a customer or business partner that refused to teach me.  They greatly appreciate your interest.  In turn, you will be surprised at how much you teach them about product development.  Spend your time here, and the question of "How do I become a VP" will take care of itself. 

Customer involvement to reduce time to satisfaction

In my previous post, I discussed time to customer satisfaction. Much has been written elsewhere about customer involvement as part of a user experience program.  Prototypes, wireframes, and other techniques are well documented. As such, I'll avoid these topics. There are, however, two items that don't receive the same level of attention (or at least I haven't seen them frequently). They are the focus of this post.

Early involvement via sprint demos

Agile advocates that stakeholders (or proxies in the form of product owners) be part of the team.  This is an admirable goal, but I've yet to see it occur in practice.  This may be due to my experience in product development companies, where the "customer" is a market, not specific people.  While I've not had the opportunity to embed customers in my teams, there are ways to integrate them in your process.

Make each product owner responsible for cultivating a cadre of users.  These users are people heavily involved in the operational workflows for which the product is intended to be used.  Beginning with the first storyboards, this collection of users participates in sprint demonstrations.  They are made aware of the user stories delivered and the user stories being considered for the next iteration.  As the product is demonstrated, they can immediately confirm or correct workflow and visual designs.  I've even witnessed users helping each other understand how to use the product, thereby eliminating feature requests entirely.

This group also is a sounding board for questions or ideas that come up during the development process.  It is not unusual for product owners to have multiple user contacts through an iteration.

Advisory boards

While iteration demonstrations are tactical, advisory boards are strategic.  Look for people with industry breadth and understanding of operations within their organizations.  Advisory boards are critical to ensuring appropriate major product features and workflows.  Instead of focusing on iteration deliverables, this group guides you to determine priorities of competing major features, high level workflows across features, and your standing relative to competitors (within ethical and legal constraints).  

You will want 8-12 people representing multiple dimensions of your product. For example, a product for physicians would have an advisory board comprised of multiple specialties, geographies, and EHR usage. I encourage you to have non-customers represented, as well. They are highly likely to provide you completely new ways of thinking about problems, since they don't "know" your product or its workflows.

Most importantly, you want this group to tell you where your strategic mistakes are - before the market does.


These two groups can tremendously impact your ability to deliver a highly acceptable product to the market. They help refine workflows and visual designs, thereby decreasing the time to customer satisfaction. Equally important, the people involved throughout take a high degree of ownership. They become product advocates, since it is their product design.

Customer satisfaction & technical debt

Time to market is a key concept for product delivery.  Reducing time to market can preempt competition, show responsiveness to customer requests, and generate revenue sooner.  It is the basis for commitments to sales, to customers, and to the market.

Without ignoring time to market, I propose you plan, design, and deliver software with an additional concept in mind: Time to customer satisfaction.  

Bringing a product to market and having satisfied customers are not the same thing.  Time to market is straightforward.  It is when the product is released to sales and to customers.  Time to customer satisfaction is difficult to measure. It is a subjective combination of a customer's willingness to purchase, deploy, and use the software.

With an ideal product delivery process, the gap between time to market and time to satisfied customers is zero.  Alas, we don't live in ideal worlds.  Periodically, the gap is significant. When this occurs, the development team incurs a subtle of technical debt.

Let me step back for a moment.  Generally, plans expect version "X" to go to market with little or no additional work.  Reported defects are handled by a maintenance or customer support team. Requested enhancements are considered for a future release.  All is good.  

But, what happens when the feature itself is rejected?

Regardless of the reason for the rejection, you are forced to repair fundamental flaws immediately. These require depth that only your development team has.

The challenge is that your development team is executing plans and commitments for version "X+1."  Those have been communicated to sales and customers.  Product delivery commitments are commitments for revenue.

Oops.

You have a few options:

• Replan and change commitments.
• Overwork your team to repair version "X" and maintain delivery of version "X+1" simultaneously.
• Cut corners on version "X+1" as much as possible without impacting revenue and customer satisfaction.

The right option depends on your business.  For example, a small start-up needing cash is going to go for the latter two choices.  Whether or not the choices are sound business decisions is irrelevant.  What matters is that they feed on themselves to increase the likelihood of a future delay in version "X+1" time to customer satisfaction.

You might say at this point, "Adjust the plan and change the commitments." That is the engineer talking, not the business person.  Changing commitments can not be taken lightly.  The consequences range from lost credibility to severe financial harm (lost contracts, stock price, etc.).  

Your goal as a development leader is to reduce the risk of a gap in time to customer satisfaction.  Now that I've introduced the concept, I'll stop here. My next post will focus on things you control (or, at least influence) to decrease time to customer satisfaction.

People over technology

I just returned from the largest healthcare technology conference in the world, HIMSS 2011. There are hundreds of vendor booths ranging from a 10 foot table to city block sized two story complexes. It seemed everywhere I turned I was told that if only my doctor had an iPhone or tablet, patients would be healed faster, medical mistakes would plummet, and hospitals would recoup more money.

There was so much technology that I found myself forgetting a basic fact. Healthcare is about healing people. And those that do the healing are people.

I didn’t recognize how little I thought about patients until I put my girls to bed tonight and began reflecting on the show. Then it hit me.

Every good and rewarding memory from the show involved people, not technology. It was the joy of being greeted with genuine fondness by former executive leaders. It was the smiles and embraces I received from past colleagues. And it was the tears when I ran into a prior customer as she turned a corner and I received the biggest hug of the entire event – and her kind and exaggerated words of thanks for the years of being a trusted partner to her organization.

We are here to apply technology so our customer’s lives may be people-centered, not gadget centered.

Regardless of your industry, remember that there is a person on the other end of your solution. Start with them and let their needs, their goals, and their hopes drive you – not the technology.

One final story.

I visited a hospice customer several years ago. After a day of IT, finance, and CIO type discussions, they asked if I’d like to tour their inpatient hospice unit. If you aren’t familiar an inpatient hospice unit, it is a place where people come to spend their last days. The average stay is measured in days, not weeks.

It was sobering to be shown a typical patient room. By itself, that would have altered my view of my product and my role in leading the team developing it.
Then I saw the computer screens at the nursing stations with my application running. At that point I could trace a path to the choices I made daily directly to the patients who were in this unit dying. It ceased to be about technology. It became a quest to build something that would allow my users (nurses) to do their job better (help people die with dignity).

Don’t lead with technology. Listen, observe, and seek to understand. Next time you find yourself getting enamored with new technology, don’t forget to ask yourself what difference it is going to make in the lives of your users.

Building Customer Friendly Teams

How do you develop wonderful user experiences if your development team has contempt for your users?

OK – I admit this may be a bit strong. But bear with me for a minute.

Think about your development team – top to bottom. Do you have folks that refuse to talk to customers? Or folks that insist they know what the customer needs, even though they have never spoken to a customer?

I’ve seen this across every company I’ve worked for, and at all levels. Sometimes it was an engineer who knew that a user “would never do something that way”. Other times it was a development leader who believed it is “Product Management’s job to talk to customers.”

In either case, you, your company, and your customers lose. I’m not going to discuss you all lose – that is better left to a different post. After all, I’m writing this post under the assumption that you want to create a customer friendly team. With that, let me share some guidelines that can help you build a customer friendly development team.

Set the tone
As the leader, you set the tone that the customer is the highest priority. In practice, this means you:

• never disparage your customers (e.g., refer to them as ‘dumb users’, etc.).
• always include customer considerations in product decisions (e.g., this feature will make our users more efficient, happier, etc).
• show respect for your customers in every interaction with them, even if your team members aren’t there.
  

Find opportunities to teach
Bring members of your team with you to visit customers, to observe end users, and to attend conferences. These are excellent environments to role model. I especially find it helpful to debrief team members on why I acted a particular way with a customer.

For example, I may agree to add a certain enhancement on behalf of a customer. I’ll share with my team member the background on why I made the commitment. For example, perhaps the request was already in the queue and will generate goodwill for a very vocal customer, at very little impact to the roadmap. Or perhaps this is a customer who provides tremendous references and has “earned” the right to get small requests periodically.

These interactions serve to teach team members that more goes into product decisions than technical decisions. This is the basis for developing future business leaders. Keep this in mind - most (all?) successful C-level people handle customers exceptionally well. Chances are they learned that skill somewhere along the way. Why not give a future CEO the chance to credit you with their success!

Expect user interaction from your team
I expect every member of my team to interact with users. That expectation drives all team behavior from hiring through annual reviews. Every one of my managers had goals associated with attending user groups or customer visits. That, in turn, set the tone for their direct reports.

As a result, team members look for opportunities to get out with customers. There are even team members who reach out to customers on their own for input during the development process. Not only does the person get great input, the customers who were asked develop greater affinity for your company and “their” product.

The investment you make in creating a customer friendly team pays dividends:

• Increased customer loyalty (Customers tend to give you the benefit of the doubt if they know you and your team care about them and their challenges)
• Better decisions (Who better to know how a feature can work best other than the people who do the job every day?)
• Higher maturity teams (Technology takes place in a context – and the context is the customer environment, not the SDLC)

Now go out and find a customer to meet.

I'm in love!

Yes, that's right. I'm in love. Oh, I've known it for some time, but I don't think I was ready to admit it. So, here I am, ready to say it to the world.

I love my customers.

OK, you may be thinking that I've lost my mind. Or, you may be wondering what the big deal is. After all, aren't we supposed to love our customers? Of course we are. But do we?

All right, let me explain.

You see, I'm privileged to work in a truly meaningful industry. As a software vendor to Home Health and Hospice providers, I have a chance to impact clinicians who are doing deeply important work. The patients my customers serve are among the sickest and most vulnerable among us. They are often faced with end of life illnesses or chronic diseases.

The choices my team and I make impact whether a clinician stumbles through a maze of screens and widgets, or seamlessly uses technology to care for a patient. My customers are real to me and to my team. When we start a project, we think of the customers that will benefit. I don't mean personas. I mean real people with real names. As we solicit input, we talk to them, share our thoughts with them, and listen to their feedback. We treat them as first-class team members - people who know what they need to get done and why.

Again, I know this isn't exactly earth-shattering. But the affection my team and I have for our customers matters. It's what drives us to spend the time and energy to get a feature from "useful" to "delightful." Affection wasn't obtained overnight. It has been cultivated through reaching out to and building relationships with our customers.

This effort pays off. I often stop by the desk of someone working late and ask them what is going on. And more often then not, the response is something like "I spoke to Sally of such and such Hospice, and she had this great feedback I wanted to mock up for the developers to get into the next sprint." You see, a User Story can wait until the next day. Helping Sally happens now.

I hope my customers know how much I care for them, and respect what they do. When things go bump in the night, sure they get frustrated and sometimes even angry. But so far, after all these years and the occasional setback, they have always trusted that I care about them and their patients. At the end of a sometimes long call, they tell me that they know my team will do whatever is necessary to allow them to do what matters: care for patients.

And when they are delighted by the software or service provided, they are equally eager to share. I guess what it comes down to is that after we look at markets and segments, personas and users, eventually you have to realize that on the other side of every decision you make is a real person.