In recent blogs I have described the steps of a problem-solving methodology that I have found works extraordinarily well in helping teams solve complex problems. What I have also found is that different team members contribute in different ways, and their contributions are better aligned with some steps of the problem-solving process than others. Imagine if there were a way to understand how each team member best contributes to the problem solving. Imagine if you had a way to ensure that there were strong contributors at each step of the way through the problem-solving process. Also, imagine if you understood when there was too much or too little representation of a particular strength so that you could avoid some classic problem-solving mistakes (for instance, paralysis by analysis.) The next sequence of blogs will describe the connection between people’s strengths and weaknesses and the process itself.
The basic premise of this discussion is that we can find a method that does provide a link between each step in the problem-solving process and people’s strengths and weaknesses. I discovered such a link while studying the Enneagram. For those of you not familiar with the Enneagram, I recommend checking out this link. I find that this book is a great introduction to the Enneagram.
During an Enneagram workshop I attended, the question was raised as to why there are numbers to describe the different personality types. The instructor indicated that the numbers are arranged in the order that people solve problems. Voila! The Enneagram not only describes 9 basic personality types, but it also describes the order in which each type contributes to a way humans solve problems. Fascinating! It was based on this bit of inspiration that I started to develop the problem-solving process I have described in previous blogs. In using this process with teams, I did find that there is a strong correlation between a person’s Enneagram type and their ability to contribute to the problem-solving process. I used this correlation to promote leadership of those with particular strengths as the team needed those strengths during a particular phase. Asking people to do what they are naturally gifted to do yields remarkable results. I believe this is one of the most powerful aspects of this problem-solving process.
Matt Schlegel has studied the Enneagram since 2001. His introduction to the Enneagram came through his family. Over time, he found that it was a useful tool in helping resolve conflicts in the workplace and getting teams to work together more effectively. He also discovered its powerful use as a problem-solving tool. Matt continues to study the Enneagram, discovering something new and interesting with every encounter.
More...
Tuesday, October 20, 2009
Saturday, October 17, 2009
Introducing Myself [Robert Lasater]
Hello everyone. My name is Robert Lasater. I am the engineer responsible for maintaining this blog.If you have issues, questions or comments, you can contact me at rlasater "at" hotmail . com
My goal for this blog is to provide a forum for people at all levels of engineering leadship. For example, as a software engineer I am an individual contributor, but I have led projects from initial requirements to full scale deployments, working with domain experts, quality assurance, and customer representatives. So I want this blog to be relevant and helpful to people like myself.
Obviously the blog should also be of help and interest to team leads - people who have one or more people reporting to them, most likely supervised by a manager or director - through managers, directors to vice presidents of engineering.
Anyway, I have been working this blog for a few weeks and look forward to working with the EL SIG team to make it a Must See site for engineering leaders in Silicon Valley and across the nation and the world.
Robert Lasater is a software developer with several years of experience leading projects to develop firmware for embedded systems.
More...
My goal for this blog is to provide a forum for people at all levels of engineering leadship. For example, as a software engineer I am an individual contributor, but I have led projects from initial requirements to full scale deployments, working with domain experts, quality assurance, and customer representatives. So I want this blog to be relevant and helpful to people like myself.
Obviously the blog should also be of help and interest to team leads - people who have one or more people reporting to them, most likely supervised by a manager or director - through managers, directors to vice presidents of engineering.
Anyway, I have been working this blog for a few weeks and look forward to working with the EL SIG team to make it a Must See site for engineering leaders in Silicon Valley and across the nation and the world.
Robert Lasater is a software developer with several years of experience leading projects to develop firmware for embedded systems.
More...
Monday, October 12, 2009
Problem Solving Tool - Step 8: Smoothing the Feathers [Matt Schlegel]
The problem-solving team has performed an apparent miracle. A transformative change has taken place in the organization. Results have been measured and confirmed – the goals that the team set out to achieve have been reached, and the problem has been solved. Is it time to celebrate? Well, hold on just a minute.
Whenever there is a transformative change within an organization, there will be perceived “winners” and “losers.” There will be those whose position in the company is apparently improved and those whose position is apparently diminished. Humans are great detectors of these types of changes – we cannot help ourselves, it is just what we do. The 8th and final step of this process (at least numerically speaking) is to reach out to all those people that are affected by the change, find out what is working well and what is not working well in the post-transformation organization.
The team is no longer selling the change. The most important skill at this point in the process is LISTENING. It is particularly important to listen to those who have undergone disruptive change in the way that they perform their function. Not only has this change been emotionally unsettling, there also may be new, unforeseen issues that are impeding workflow. It is important to capture these issues and concerns, address them as well as possible, and ensure that all workflows are moving effectively.
Continuous Improvement
Inevitably, there will be some issues raised during this final listening step of great enough magnitude as to require more than a quick and simple fix. Capture those issues. The interesting thing about this process is that it is not linear, but circular. After the change, new problems arise and can be addressed with the same process, back to step #1. In this manner, an organization can be continually evaluating its effectiveness and taking the steps necessary to improve itself in a never ending cycle, a cycle of continuous improvement.
Time to Celebrate
Okay, the team has taken the time to listen to those who have concerns. You have implemented quick fixes to address the simple concerns, and have recorded those concerns of greater magnitude for careful consideration later. Importantly, you have included all those affected and taken the time to smooth any ruffled feathers. Now, it is time to celebrate! The problem is solved, the metaphoric dragon slain. Take the time to enjoy your success as a team. You deserve it.
In the next series of blogs I will return to the idea of sharing leadership during the problem-solving process.
As an engineering manager, Matt Schlegel had the opportunity to organize/sponsor some memorable celebrations. His favorites to date are canoeing on the Russian River, kayaking in Elkhorn Slough, and cooking at Culinary Center of Monterey. What have been your most memorable team celebrations?
More...
Whenever there is a transformative change within an organization, there will be perceived “winners” and “losers.” There will be those whose position in the company is apparently improved and those whose position is apparently diminished. Humans are great detectors of these types of changes – we cannot help ourselves, it is just what we do. The 8th and final step of this process (at least numerically speaking) is to reach out to all those people that are affected by the change, find out what is working well and what is not working well in the post-transformation organization.
The team is no longer selling the change. The most important skill at this point in the process is LISTENING. It is particularly important to listen to those who have undergone disruptive change in the way that they perform their function. Not only has this change been emotionally unsettling, there also may be new, unforeseen issues that are impeding workflow. It is important to capture these issues and concerns, address them as well as possible, and ensure that all workflows are moving effectively.
Continuous Improvement
Inevitably, there will be some issues raised during this final listening step of great enough magnitude as to require more than a quick and simple fix. Capture those issues. The interesting thing about this process is that it is not linear, but circular. After the change, new problems arise and can be addressed with the same process, back to step #1. In this manner, an organization can be continually evaluating its effectiveness and taking the steps necessary to improve itself in a never ending cycle, a cycle of continuous improvement.
Time to Celebrate
Okay, the team has taken the time to listen to those who have concerns. You have implemented quick fixes to address the simple concerns, and have recorded those concerns of greater magnitude for careful consideration later. Importantly, you have included all those affected and taken the time to smooth any ruffled feathers. Now, it is time to celebrate! The problem is solved, the metaphoric dragon slain. Take the time to enjoy your success as a team. You deserve it.
In the next series of blogs I will return to the idea of sharing leadership during the problem-solving process.
As an engineering manager, Matt Schlegel had the opportunity to organize/sponsor some memorable celebrations. His favorites to date are canoeing on the Russian River, kayaking in Elkhorn Slough, and cooking at Culinary Center of Monterey. What have been your most memorable team celebrations?
More...
Friday, October 2, 2009
You Say “Later”, They Hear “Never” [Tanya Berezin]
I don’t have a crystal ball but this I can see without one. If you manage software development projects, this will happen on your next one:
You’ll need to deal with the immediate issue of salvaging your release and the longer term need to reestablish your credibility with the customers.
The immediate problem usually is somewhat straightforward. If you cannot get more resources - time, people, money, tools, etc. - and you cannot compromise quality, you’ll have to work with your customers to cut some planned features. Once you agree on what gets cut, they’ll want to know when the cut features will make it into the product. And, sometimes silently and sometimes out loud, they’ll wonder if these features will ever make it in.
You can’t blame them for being suspicious: they’ve had to postpone features on other projects before and in many cases these features never got implemented at all. But you need to tackle this concern quickly and persuasively, or negotiating scope again in the future will be much, much harder.
I will assume the features you postponed are worth implementing. (See my previous post on how to artfully say “no” to unnecessary work.) How will you assure your customers that you are only delaying the work, not burying it permanently?
1. Show the backlog.
Use your project backlog, product roadmap, or another list that shows planned features in priority order. (You don’t have one? Put one together as soon as you can.) Your customers worked with you on it, so pull it out and remind them what you were thinking of when you prioritized the list. If the business context has changed, now is a very good time to review and change this list. If not, your customers will be reminded that you were planning all along to add features over time and that hasn’t changed.
2. Discuss risks.
Acknowledge that reality can intervene with your best intentions. Your project could lose the backing of your sponsor; a new competitor could show up and you’d have to change what you are doing; or any of hundreds of other things quite outside of your control could happen. (For a list of typical project risks go to www.construx.com and navigate to the Resources & Tools section.) Show your customer your top risks list (you have one, right?) and your contingency and prevention plans for each. This will reassure them that you are doing all you can to protect the planned features from being permanently on hold.
3. Deliver.
Of course, the best thing you can do to maintain your credibility is to deliver what you promise. So when you do cut scope for one release, don’t overpromise for the next one. Keep track of what you estimated your team could do and what they actually did and improve your estimates over time.
This way, next time you say “later” to a feature, your customers won’t hear “never!”
Tanya Berezin is a successful software development leader who consistently delivers complex, bet-the business, need-it-yesterday projects. She enjoys building high-performing teams who delight customers with easy to use products. Find more information about her at http://www.linkedin.com/in/tanyaberezin
More...
- Customers (or Marketing or Product Management) will want more than your team can deliver.
- It will be your job to tell them that.
- They won’t be happy.
You’ll need to deal with the immediate issue of salvaging your release and the longer term need to reestablish your credibility with the customers.
The immediate problem usually is somewhat straightforward. If you cannot get more resources - time, people, money, tools, etc. - and you cannot compromise quality, you’ll have to work with your customers to cut some planned features. Once you agree on what gets cut, they’ll want to know when the cut features will make it into the product. And, sometimes silently and sometimes out loud, they’ll wonder if these features will ever make it in.
You can’t blame them for being suspicious: they’ve had to postpone features on other projects before and in many cases these features never got implemented at all. But you need to tackle this concern quickly and persuasively, or negotiating scope again in the future will be much, much harder.
I will assume the features you postponed are worth implementing. (See my previous post on how to artfully say “no” to unnecessary work.) How will you assure your customers that you are only delaying the work, not burying it permanently?
1. Show the backlog.
Use your project backlog, product roadmap, or another list that shows planned features in priority order. (You don’t have one? Put one together as soon as you can.) Your customers worked with you on it, so pull it out and remind them what you were thinking of when you prioritized the list. If the business context has changed, now is a very good time to review and change this list. If not, your customers will be reminded that you were planning all along to add features over time and that hasn’t changed.
2. Discuss risks.
Acknowledge that reality can intervene with your best intentions. Your project could lose the backing of your sponsor; a new competitor could show up and you’d have to change what you are doing; or any of hundreds of other things quite outside of your control could happen. (For a list of typical project risks go to www.construx.com and navigate to the Resources & Tools section.) Show your customer your top risks list (you have one, right?) and your contingency and prevention plans for each. This will reassure them that you are doing all you can to protect the planned features from being permanently on hold.
3. Deliver.
Of course, the best thing you can do to maintain your credibility is to deliver what you promise. So when you do cut scope for one release, don’t overpromise for the next one. Keep track of what you estimated your team could do and what they actually did and improve your estimates over time.
This way, next time you say “later” to a feature, your customers won’t hear “never!”
Tanya Berezin is a successful software development leader who consistently delivers complex, bet-the business, need-it-yesterday projects. She enjoys building high-performing teams who delight customers with easy to use products. Find more information about her at http://www.linkedin.com/in/tanyaberezin
More...
Saturday, September 26, 2009
Problem Solving Tool - Step 7: Git’er Done [Matt Schlegel]
Finally, finally, FINALLY! – finally, we are at the step in the process where we actually DO something. We have been talking, talking, talking – all we have done is talk in circles. Now, we finally get to the DOING. It is hard to believe that we have spent so much time thinking and talking. What a waste of time! Let’s get down to the business of solving the problem. Let’s git’er done.
Know anyone who might say that?
Well, they are correct. To this point I have described 6 steps, none of which have actually solved the problem. Furthermore, to describe those steps, I have written 9 blogs. In all that, we really haven’t “done” a thing to solve the problem itself. Can you imagine the time and patience a team would have to go through to get to this point without actually jumping in to solve the problem? It is very tough to imagine for the git’er-done person who spoke in the first paragraph. Well, what have we accomplished? This is a good time to summarize:
1. We have described the problem and established goals
2. We have built a team and defined the roles and responsibilities of its members
3. We have generated a rich set of creative ideas from which to draw
4. We have analyzed those ideas and uncovered the costs and benefits of each
5. We have built a plan around the best set of ideas that will meet the goals, solve the problem
6. And, we have obtained permission to execute that plan
So, yes, while that has been mostly talking, the team has laid the foundation upon which to successfully implement a solution to the problem, and that foundation has buy-in from the stakeholders who have committed the resources necessary to accomplish the goals.
Start Small
Practically speaking, the implementation step often takes the most time. In fact, depending on the goals the team has set out to accomplish, this phase could take more time than the first six steps combined. During this implementation phase, I have found that starting small and building on successes is a great recipe to keep up the momentum. For instance, when implementing solutions that will affect a company’s product development process, I advise the team to pick just one project and prototype the solution with only that one product development team. Working with that one team, you can learn what works and what doesn’t. You can develop the materials you will need to communicate the solutions to other teams. And you can demonstrate the positive effects that the solutions have on the product development outcome. All of this makes it just that much easier for each successive product development team to adopt the solution. After a while, all the teams are using the proposed solution, mitigating the problem and accomplishing the goal.
Git’er done
And, if you know someone who might say what I wrote in the first paragraph, they may be a good candidate to take the lead during this phase of the problem-solving process. This phase is about action and the ideal person is an action-oriented leader, perhaps a team stakeholder with a program management background, who will drive the implementation and not be afraid to ruffle a few feathers along the way if that is what it takes. And, whenever you try to accomplish something big and important, feathers will be ruffled. I will address this issue in the next blog.
Matt Schlegel has a bias toward actions and has been reminded, on occasion, that he is a human “being” not a human “doing.”
More...
Know anyone who might say that?
Well, they are correct. To this point I have described 6 steps, none of which have actually solved the problem. Furthermore, to describe those steps, I have written 9 blogs. In all that, we really haven’t “done” a thing to solve the problem itself. Can you imagine the time and patience a team would have to go through to get to this point without actually jumping in to solve the problem? It is very tough to imagine for the git’er-done person who spoke in the first paragraph. Well, what have we accomplished? This is a good time to summarize:
1. We have described the problem and established goals
2. We have built a team and defined the roles and responsibilities of its members
3. We have generated a rich set of creative ideas from which to draw
4. We have analyzed those ideas and uncovered the costs and benefits of each
5. We have built a plan around the best set of ideas that will meet the goals, solve the problem
6. And, we have obtained permission to execute that plan
So, yes, while that has been mostly talking, the team has laid the foundation upon which to successfully implement a solution to the problem, and that foundation has buy-in from the stakeholders who have committed the resources necessary to accomplish the goals.
Start Small
Practically speaking, the implementation step often takes the most time. In fact, depending on the goals the team has set out to accomplish, this phase could take more time than the first six steps combined. During this implementation phase, I have found that starting small and building on successes is a great recipe to keep up the momentum. For instance, when implementing solutions that will affect a company’s product development process, I advise the team to pick just one project and prototype the solution with only that one product development team. Working with that one team, you can learn what works and what doesn’t. You can develop the materials you will need to communicate the solutions to other teams. And you can demonstrate the positive effects that the solutions have on the product development outcome. All of this makes it just that much easier for each successive product development team to adopt the solution. After a while, all the teams are using the proposed solution, mitigating the problem and accomplishing the goal.
Git’er done
And, if you know someone who might say what I wrote in the first paragraph, they may be a good candidate to take the lead during this phase of the problem-solving process. This phase is about action and the ideal person is an action-oriented leader, perhaps a team stakeholder with a program management background, who will drive the implementation and not be afraid to ruffle a few feathers along the way if that is what it takes. And, whenever you try to accomplish something big and important, feathers will be ruffled. I will address this issue in the next blog.
Matt Schlegel has a bias toward actions and has been reminded, on occasion, that he is a human “being” not a human “doing.”
More...
Sunday, September 6, 2009
Problem Solving Tool - Step 6: Tapping your Inner Medieval Salesperson [Matt Schlegel]
After a much too brief summer break, I pick up where I left off. In the last blog I wrote about Step 5, creating a plan to solve your team’s big problem. This step I affectionately referred to as “The Path of Least Danger.” Now that your team has constructed the path, it is time to start the journey down that path, right? Well, not quite yet. Your core, problem-solving team may be revved up and ready to charge down that path, but the wider group of stakeholders may not be there, yet. At this point, it is time to bring the wider group of stakeholders, including the executive sponsors, up to that same level of enthusiasm. It is time to sell your plan.
Folks in sales will understand this phase of the problem-solving process very well. When facilitating problem-solving groups at this phase, I recommend that the team create a presentation that tells a story. The first part of that story sets the stage: you remind your stakeholders of the pain that they are experiencing because of their very big problem. To make this more dramatic, let’s call the problem “the Dragon.” Then, you introduce your heroes, the highly credible team of talented folks that want to slay the Dragon. You may want to share some examples of havoc wreaked by the Dragon, and some stories of early, unsuccessful attempts to slay the Dragon. Then, you will want to share the insight that your heroes had that exposed the path to the Dragon’s weakness. Finally, your story will explain the careful preparation that the heroes have made to march down that path and destroy the Dragon once and for all. And, there you stop.
What do you think that your executive sponsor/decision maker will do at this point? In my experience, having facilitated this process over a dozen times, the response is unequivocally – Go Slay That Dragon! I have found that all reasonable requests for resources - people, capital and cash – are made available for the Dragon Slaying Quest. Also, there is a strong sense of empathy about the shared problem and anticipation of a world in which the Dragon is eliminated. That anticipation is infectious – certainly the executive sponsors feel it. Also, the broader organization will eagerly support our heroes in their quest. That wide-spread support is certainly important since killing this Dragon will not be easy and will require everyone’s cooperation.
I may have stretched the Dragon metaphor to the limits here, but I think it does highlight the important step of having the team get direct permission from the executive sponsors to proceed with expending company resources to solve the big problem. The manner in which this is done is very similar to a sales process. I recommend that the team enlist the help of an enthusiastic, people-oriented salesperson-type to assist the team in both creating and telling your compelling story. With that permission, we then arrive at Step 7 in which you solve your problem. I will describe this step in the next blog.
Growing up, Matt Schlegel was much more interested in riding dragons than slaying them and fondly recalls reading the Dragonriders of Pern by Anne McCaffrey.
More...
Folks in sales will understand this phase of the problem-solving process very well. When facilitating problem-solving groups at this phase, I recommend that the team create a presentation that tells a story. The first part of that story sets the stage: you remind your stakeholders of the pain that they are experiencing because of their very big problem. To make this more dramatic, let’s call the problem “the Dragon.” Then, you introduce your heroes, the highly credible team of talented folks that want to slay the Dragon. You may want to share some examples of havoc wreaked by the Dragon, and some stories of early, unsuccessful attempts to slay the Dragon. Then, you will want to share the insight that your heroes had that exposed the path to the Dragon’s weakness. Finally, your story will explain the careful preparation that the heroes have made to march down that path and destroy the Dragon once and for all. And, there you stop.
What do you think that your executive sponsor/decision maker will do at this point? In my experience, having facilitated this process over a dozen times, the response is unequivocally – Go Slay That Dragon! I have found that all reasonable requests for resources - people, capital and cash – are made available for the Dragon Slaying Quest. Also, there is a strong sense of empathy about the shared problem and anticipation of a world in which the Dragon is eliminated. That anticipation is infectious – certainly the executive sponsors feel it. Also, the broader organization will eagerly support our heroes in their quest. That wide-spread support is certainly important since killing this Dragon will not be easy and will require everyone’s cooperation.
I may have stretched the Dragon metaphor to the limits here, but I think it does highlight the important step of having the team get direct permission from the executive sponsors to proceed with expending company resources to solve the big problem. The manner in which this is done is very similar to a sales process. I recommend that the team enlist the help of an enthusiastic, people-oriented salesperson-type to assist the team in both creating and telling your compelling story. With that permission, we then arrive at Step 7 in which you solve your problem. I will describe this step in the next blog.
Growing up, Matt Schlegel was much more interested in riding dragons than slaying them and fondly recalls reading the Dragonriders of Pern by Anne McCaffrey.
More...
Wednesday, September 2, 2009
Say No in a Delightful Way [Tanya Berezin]
We’ve all been there: your product manager comes to you with a great feature idea. You – the engineering manager – know your team is already stretched implementing the other great features scheduled for the next release. You offer to prioritize the new feature against others already scheduled and the two of you agree on a reasonable scope for the release.
It’s all very logical but doesn’t feel good. The product manager is disappointed with you: you always seem to throw cold water on his ideas. And you are annoyed, too: you wish the product manager would let you focus on delivering what’s already agreed on. Time to try something different.
Do you know why the product manager is excited about the feature? Find out: have her walk you through her thinking – what customer need does the feature meet? How many customers might need it? Is the need urgent? Are we going to make more money from it?
As you think through these questions together, the PM begins to see that you both are genuinely interested in making the product better for your customers. All of a sudden, you seem a lot less rejecting – a win for your relationship. In addition, if your PM is inexperienced and has no answer to these questions, you’ve just taught her how to be a better product manager. And if this conversation leads you to conclude that the idea isn’t as hot as it seemed at first, the extra work for your team has been headed off, never to come back.
Let’s suppose you, too, are now a believer. Are you sure your customers will be as enthusiastic as the two of you? With a little ingenuity you can find a way to test the feature with customers without needing any engineering work upfront (think low fidelity prototypes, user surveys, etc.) Thus, you and your PM have moved forward with the idea while your engineers still haven’t been handed any extra work.
(This isn’t as much work as it may seem – many times, I’ve done both of these steps in a 30 minute meeting. Last time, as the PM left my office, eager to get started, she said: “I came to ask for engineering time and you just said ‘no’ to me, didn’t you? But I couldn’t be happier. How did you do that?”)
OK, you’ve tested the feature with customers and they seem really jazzed about it. Is now the time to have the re-prioritization discussion we started with? Not quite yet; instead, can you think of a different way to meet the customer need using the features you already have? All the research you’ve just done may give you ideas on how to do that. If you do, the extra work for the new feature may never need to be done.
If after all this you are still convinced that the new feature is worth the extra development effort, then you should put it in your backlog and prioritize. But this time, the prioritization discussion will feel very different: the product manager won’t feel thwarted and you won’t feel jerked around. In fact, you’ll be delighted with each other!
Tanya Berezin is a successful software development leader who consistently delivers complex, bet-the business, need-it-yesterday projects. She enjoys building high-performing teams who delight customers with easy to use products. Find more information about her at http://www.linkedin.com/in/tanyaberezin
More...
It’s all very logical but doesn’t feel good. The product manager is disappointed with you: you always seem to throw cold water on his ideas. And you are annoyed, too: you wish the product manager would let you focus on delivering what’s already agreed on. Time to try something different.
Do you know why the product manager is excited about the feature? Find out: have her walk you through her thinking – what customer need does the feature meet? How many customers might need it? Is the need urgent? Are we going to make more money from it?
As you think through these questions together, the PM begins to see that you both are genuinely interested in making the product better for your customers. All of a sudden, you seem a lot less rejecting – a win for your relationship. In addition, if your PM is inexperienced and has no answer to these questions, you’ve just taught her how to be a better product manager. And if this conversation leads you to conclude that the idea isn’t as hot as it seemed at first, the extra work for your team has been headed off, never to come back.
Let’s suppose you, too, are now a believer. Are you sure your customers will be as enthusiastic as the two of you? With a little ingenuity you can find a way to test the feature with customers without needing any engineering work upfront (think low fidelity prototypes, user surveys, etc.) Thus, you and your PM have moved forward with the idea while your engineers still haven’t been handed any extra work.
(This isn’t as much work as it may seem – many times, I’ve done both of these steps in a 30 minute meeting. Last time, as the PM left my office, eager to get started, she said: “I came to ask for engineering time and you just said ‘no’ to me, didn’t you? But I couldn’t be happier. How did you do that?”)
OK, you’ve tested the feature with customers and they seem really jazzed about it. Is now the time to have the re-prioritization discussion we started with? Not quite yet; instead, can you think of a different way to meet the customer need using the features you already have? All the research you’ve just done may give you ideas on how to do that. If you do, the extra work for the new feature may never need to be done.
If after all this you are still convinced that the new feature is worth the extra development effort, then you should put it in your backlog and prioritize. But this time, the prioritization discussion will feel very different: the product manager won’t feel thwarted and you won’t feel jerked around. In fact, you’ll be delighted with each other!
Tanya Berezin is a successful software development leader who consistently delivers complex, bet-the business, need-it-yesterday projects. She enjoys building high-performing teams who delight customers with easy to use products. Find more information about her at http://www.linkedin.com/in/tanyaberezin
More...
Subscribe to:
Posts (Atom)
