Product Develoment Archives - Henning Kristensen Product Development http://henningkristensen.com/category/product-development/ Product Development Consultant Wed, 17 Aug 2016 02:59:29 +0000 en-US hourly 1 https://i0.wp.com/henningkristensen.com/wp-content/uploads/2015/11/cropped-project-development-consultant-henning-kristensen-logo.png?fit=32%2C32 Product Develoment Archives - Henning Kristensen Product Development http://henningkristensen.com/category/product-development/ 32 32 113828529 The Future of New Product Management http://henningkristensen.com/the-future-new-product-management/ http://henningkristensen.com/the-future-new-product-management/#comments Wed, 17 Aug 2016 01:48:28 +0000 http://henningkristensen.com/?p=5968 The cloud is here to stay, we’re using more mobile data than ever, micro interactions are in, fully flat design may be on its way out, and Oxford’s word of the year is an emoji. But what’s on the horizon for product management and project leadership? Here are four new product management trends we’ll see dominating the scene in 2016:

Data-Driven Product Development is Here to Stay

The amount of data available to decision makers has grown exponentially as connectivity and data collection have become ubiquitous. This has left leadership spoiled for choice in this department, their questions are no longer “can we measure it?” but rather “which metric(s) should we care about?”

Product management decisions must be supported by data, and once they’re executed you’ll need the data to show they were the right decisions… and then you or your development engineers will use that data to make your next decisions.

Anecdotes and hunches need not apply in the new world of product management.

“You can’t rely on your gut instinct all the time. The numbers will show there’s a little bit of hubris in thinking that you know better or your gut instinct is correct,” says Maggie Jan, Data Scientist at Keen.io, adding “You’ve gotta have a healthy amount of skepticism when you go back and evaluate what works and what doesn’t.”

As companies embrace data, they’re often looking at the product development team to be the fulcrum for collecting and analyzing this data and turning it into something actionable. Nearly every product manager job listing includes “data-driven” in the first few lines of the job description, further highlighting the importance of this approach.

 

“Every company wants to be data-driven these days basically for good reason, thorough analysis and testing of hypotheses using data is the best and most sustainable way of improving products and services,” says Lars Trieloff, Director of Product Management at Blue Yonder.

The availability of and reliance on data can also help wrangle product development teams and keep them focused on the initiatives that will truly make a meaningful impact and not just on crossing off the next thing on the list.

“One of the most difficult problems rapidly-growing tech start-ups face is escaping the frantic, executional culture that is imperative to early success,” says Daniel Mason, Data Scientist at Belly, “When each decision is infused with data and armed with statistical certainty, the chances of being successful are greatly heightened.”

3. Customer-Centric Development: Putting Customers Front and Center.

While the plethora of data points can make end users seem like just another number, companies are countering this instinct by instilling new product management scheme such as customer-first mentalities into their approaches.

“The job of a product manager isn’t to understand analytics, it is to understand customers,” says Matt LeMay, co-founder of Constellate Data,

“The idea that we can understand people without listening to them is hubristic, narrow-minded and, frankly, sad. Talking to actual humans can be confusing, awkward, and even downright discouraging. But if we really want to understand customers, we need to accept and embrace that people are not fully predictable and quantifiable.”

One reason companies are now investing in customer centric development is that they can afford to do it again – many were hamstrung during the belt-tightening days of the recession but now have enough money in the bank to shift the focus from cutting costs to customer needs. And they’re realizing that it’s worth the investment, as customer-centric companies are 60% more profitable than their peers (according to Deloitte & Touche).

Customer-centric companies are 60% more profitable than their peers

But becoming customer-centric is easier said than done, since it can require some fundamental changes in how a company operates. Switching to “solution sales” and emphasizing lifetime value vs. one-time transactions are essential building blocks.

Even older, established technology companies have shifted into customer-centric mode, with firms like IBM adopting “Design Thinking” where designers interact with users one-on-one to develop empathy for what users are trying to accomplish. This shifts the thinking from “how they’re trying to use our product” to “what they’re trying to accomplish with our product.” But you can’t do that without talking and listening to customers this is achieved through the agile project management method.

For organizations and technical project managers stuck in their ways, this process can take time and effort, but the market is demanding it from their vendors. Shifting KPIs toward lower churn rates and higher customer lifetime values gets the entire organization on board with this belief.

But most important of all, you can’t introduce new product management system or become customer centric without talking to customers… a lot. This often starts with the CEO but usually ends with the product manager and project leadership, who are tasked with using all of this great knowledge and insight gleaned from customer interviews, ride-along and surveys and turning it into fantastic requirements, customer-minded product roadmaps and smart prioritization.

3. Transparency is the New Black

While a few companies still cherish the “big reveal” events where they show off the latest smartphone or electric car, many companies are beginning to embrace a more fluid set of interactions with customers where they are quite open about what they’re building and when they will deliver it.

Fears clouding technical project managers has traditionally been the primary motivation for keeping product plans under wraps; both fear of the competition catching up or beating you to the punch and fear that too much customer communication during the product development cycle will lead to a design-by-committee environment where every product turns into a Swiss army knife that ships late and doesn’t do anything particularly well.

Fear has traditionally been the primary motivation for keeping product plans under wraps

But letting customers know about your new product management scheme and what you’re building ahead of time has some major positives as well. One plus is that customers are far more likely to buy earlier in a product’s lifecycle since they are not only buying the current features, but also the promise of what’s to come.

Another benefit is that giving customers a peek at what’s behind the curtains (new product management scheme) might head off some big problems down the line. Taking advance customer feedback (with a healthy pinch of salt) could reveal new opportunities or unchecked boxes that can now be addressed to turn your next launch from a dud into a stud.

“Your product’s growth is dependent on your ability to listen, gather feedback and iterate,” says Cat Noone, co-founder of Liberio, “If you skip this, and base your roadmap entirely on assumptions, you get the messy mountain MVP that inevitably results in the product’s downfall.”

 

This doesn’t mean you have to go over the top and make salary information public knowledge like Buffer did, but companies are continuing the trend of letting the cat out of the bag earlier, whether it is blogging about products before they’re released to build demand and create credibility in the market or frequently sharing roadmaps with customers and advisory to solicit feedback and generate buzz.

4. The Continuing Spread of Agile & Lean

Neither Agile development or Lean methodologies are particularly new at this point, but they are no longer relegated to engineering teams and scrappy start-ups. Companies of all shapes, sizes, and vintages are realizing the benefits they can bring, adopting and adapting them to fit their own purposes.

In 2011, Microsoft committed to Agile, and by 2015 they had completely transformed their organization, with 35 Agile teams in their Developer Division alone and nearly 100 sprints under their belts – they even scrapped the individual offices Redmond was so well known for 15 years after its birth, Agile is spreading beyond pure IT computer-aided industrial design engineering and code-related projects, largely because freelance or real time project managers are bringing the discipline (agile project management methodology) along with them when they are assigned to manage other initiatives. They know it works, they know how to do it, and they’re familiar with the tools already. Once you swap out the tech-centric terminology, the approach works for almost anything.

Marketing is one discipline where the measurability and rapid response capabilities of an Agile approach has caught on and continues to grow. “Before our agile processes we were creating content, but at a plodding pace,” says Andrea Fryyear, Agile Content Marketer at Widgix, “Now that we can more accurately measure our team’s bandwidth, we can devote time each sprint to creating and distributing content.”

Even lawyers are getting into the act. Jason Gershenson, an independent technology attorney gave it a try and isn’t looking back. “I love being able to see all of my work in progress at a glance, and having the steps in my workflow laid out visually really focuses me on finishing tasks and delivering work—work that I get paid for—to my clients.”

And while some may not realize the older Lean methodology didn’t spring from scrappy software start-ups (it was actually the manufacturing industry), it’s now being utilized in a wide variety of settings including healthcare, government, military, development engineering and education. Just like Agile, Lean is also being applied to more and more non-technical aspects of company operations. For example, in the sales process Lean is used to emphasize lead scoring and qualifying prospects before sales team members invest their time in pursuing opportunities, as well as standardizing the approaches and tools used to close deals.

 

 

The post The Future of New Product Management appeared first on Henning Kristensen Product Development.

]]> Data-Driven Product Development is Here to Stay The amount of data available to decision makers has grown exponentially as connectivity and data collection have become ubiquitous. This has left leadership spoiled for choice in this department, their questions are no longer “can we measure it?” but rather “which metric(s) should we care about?” Product management decisions must be supported by data, and once they’re executed you’ll need the data to show they were the right decisions… and then you or your development engineers will use that data to make your next decisions. Anecdotes and hunches need not apply in the new world of product management. “You can’t rely on your gut instinct all the time. The numbers will show there’s a little bit of hubris in thinking that you know better or your gut instinct is correct,” says Maggie Jan, Data Scientist at Keen.io, adding “You’ve gotta have a healthy amount of skepticism when you go back and evaluate what works and what doesn’t.” As companies embrace data, they’re often looking at the product development team to be the fulcrum for collecting and analyzing this data and turning it into something actionable. Nearly every product manager job listing includes “data-driven” in the first few lines of the job description, further highlighting the importance of this approach.   “Every company wants to be data-driven these days basically for good reason, thorough analysis and testing of hypotheses using data is the best and most sustainable way of improving products and services,” says Lars Trieloff, Director of Product Management at Blue Yonder. The availability of and reliance on data can also help wrangle product development teams and keep them focused on the initiatives that will truly make a meaningful impact and not just on crossing off the next thing on the list. “One of the most difficult problems rapidly-growing tech start-ups face is escaping the frantic, executional culture that is imperative to early success,” says Daniel Mason, Data Scientist at Belly, “When each decision is infused with data and armed with statistical certainty, the chances of being successful are greatly heightened.”

3. Customer-Centric Development: Putting Customers Front and Center.

While the plethora of data points can make end users seem like just another number, companies are countering this instinct by instilling new product management scheme such as customer-first mentalities into their approaches. “The job of a product manager isn’t to understand analytics, it is to understand customers,” says Matt LeMay, co-founder of Constellate Data, “The idea that we can understand people without listening to them is hubristic, narrow-minded and, frankly, sad. Talking to actual humans can be confusing, awkward, and even downright discouraging. But if we really want to understand customers, we need to accept and embrace that people are not fully predictable and quantifiable.” One reason companies are now investing in customer centric development is that they can afford to do it again – many were hamstrung during the belt-tightening days of the recession but now have enough money in the bank to shift the focus from cutting costs to customer needs. And they’re realizing that it’s worth the investment, as customer-centric companies are 60% more profitable than their peers (according to Deloitte & Touche).
Customer-centric companies are 60% more profitable than their peers
But becoming customer-centric is easier said than done, since it can require some fundamental changes in how a company operates. Switching to “solution sales” and emphasizing lifetime value vs. one-time transactions are essential building blocks. Even older, established technology companies have shifted into customer-centric mode, with firms like IBM adopting “Design Thinking” where designers interact with users one-on-one to develop empathy for what users are trying to accomplish. This shifts the thinking from “how they’re trying to use our product” to “what they’re trying to accomplish with our product.” But you can’t do that without talking and listening to customers this is achieved through the agile project management method. For organizations and technical project managers stuck in their ways, this process can take time and effort, but the market is demanding it from their vendors. Shifting KPIs toward lower churn rates and higher customer lifetime values gets the entire organization on board with this belief. But most important of all, you can’t introduce new product management system or become customer centric without talking to customers… a lot. This often starts with the CEO but usually ends with the product manager and project leadership, who are tasked with using all of this great knowledge and insight gleaned from customer interviews, ride-along and surveys and turning it into fantastic requirements, customer-minded product roadmaps and smart prioritization.

3. Transparency is the New Black

While a few companies still cherish the “big reveal” events where they show off the latest smartphone or electric car, many companies are beginning to embrace a more fluid set of interactions with customers where they are quite open about what they’re building and when they will deliver it. Fears clouding technical project managers has traditionally been the primary motivation for keeping product plans under wraps; both fear of the competition catching up or beating you to the punch and fear that too much customer communication during the product development cycle will lead to a design-by-committee environment where every product turns into a Swiss army knife that ships late and doesn’t do anything particularly well. Fear has traditionally been the primary motivation for keeping product plans under wraps But letting customers know about your new product management scheme and what you’re building ahead of time has some major positives as well. One plus is that customers are far more likely to buy earlier in a product’s lifecycle since they are not only buying the current features, but also the promise of what’s to come. Another benefit is that giving customers a peek at what’s behind the curtains (new product management scheme) might head off some big problems down the line. Taking advance customer feedback (with a healthy pinch of salt) could reveal new opportunities or unchecked boxes that can now be addressed to turn your next launch from a dud into a stud. “Your product’s growth is dependent on your ability to listen, gather feedback and iterate,” says Cat Noone, co-founder of Liberio, “If you skip this, and base your roadmap entirely on assumptions, you get the messy mountain MVP that inevitably results in the product’s downfall.”   This doesn’t mean you have to go over the top and make salary information public knowledge like Buffer did, but companies are continuing the trend of letting the cat out of the bag earlier, whether it is blogging about products before they’re released to build demand and create credibility in the market or frequently sharing roadmaps with customers and advisory to solicit feedback and generate buzz.

4. The Continuing Spread of Agile & Lean

Neither Agile development or Lean methodologies are particularly new at this point, but they are no longer relegated to engineering teams and scrappy start-ups. Companies of all shapes, sizes, and vintages are realizing the benefits they can bring, adopting and adapting them to fit their own purposes. In 2011, Microsoft committed to Agile, and by 2015 they had completely transformed their organization, with 35 Agile teams in their Developer Division alone and nearly 100 sprints under their belts – they even scrapped the individual offices Redmond was so well known for 15 years after its birth, Agile is spreading beyond pure IT computer-aided industrial design engineering and code-related projects, largely because freelance or real time project managers are bringing the discipline (agile project management methodology) along with them when they are assigned to manage other initiatives. They know it works, they know how to do it, and they’re familiar with the tools already. Once you swap out the tech-centric terminology, the approach works for almost anything. Marketing is one discipline where the measurability and rapid response capabilities of an Agile approach has caught on and continues to grow. “Before our agile processes we were creating content, but at a plodding pace,” says Andrea Fryyear, Agile Content Marketer at Widgix, “Now that we can more accurately measure our team’s bandwidth, we can devote time each sprint to creating and distributing content.” Even lawyers are getting into the act. Jason Gershenson, an independent technology attorney gave it a try and isn’t looking back. “I love being able to see all of my work in progress at a glance, and having the steps in my workflow laid out visually really focuses me on finishing tasks and delivering work—work that I get paid for—to my clients.” And while some may not realize the older Lean methodology didn’t spring from scrappy software start-ups (it was actually the manufacturing industry), it’s now being utilized in a wide variety of settings including healthcare, government, military, development engineering and education. Just like Agile, Lean is also being applied to more and more non-technical aspects of company operations. For example, in the sales process Lean is used to emphasize lead scoring and qualifying prospects before sales team members invest their time in pursuing opportunities, as well as standardizing the approaches and tools used to close deals.    

The post The Future of New Product Management appeared first on Henning Kristensen Product Development.

]]> http://henningkristensen.com/the-future-new-product-management/feed/ 21 5968 5 Tricks required to be a Superior Technical Project Manager. Amazing!!!. http://henningkristensen.com/5-things-takes-superior-technical-project-manager/ http://henningkristensen.com/5-things-takes-superior-technical-project-manager/#comments Thu, 04 Aug 2016 09:47:10 +0000 http://henningkristensen.com/?p=5932

To be effective as a Techical Project Manager, technical excellence is not enough. On top of that there are several other aspects on which a great professional should focus. Near the top of my list there is the ability to interact with other people involved in the project. Whatever is the nature of your project you will need to interact to get things done :

  • as an open-source contributor you have to collaborate reviewing patches or having your patches reviewed, you have to address the issues brought up by users, you want to communicate your features to new users, planning with other committers or co-maintainers
  • as a freelance you have to interact with the current customers and with potential ones. You have also to interact with other developers or designers or testers involved in the projects and you need to communicate clearly who is responsible for what
  • when working in a company you have to coordinate with the other developers, in your team and in other teams, to communicate with your manager and most importantly to interact with project managers

Developers and PMs… not always love at first sight

Relationships with the Project Managers can be a bit controversial from time to time: we as developers are very prone to complain about them. After all, they are the ones bothering us about some change that needs to go in at 6 PM on a Friday. Or the ones who keep pushing for features which do not make sense to us.

However, I think that Project Managers play a fundamental role in successful team. And as a developer i can be successful only if the team is successful. For this reason, I think that having a great relationship with Project Managers is they key for delivering results. I was lucky enough to work with amazing Project Managers that really helped me. This was especially true when I was at TripAdvisor: there I met PMs who were absolutely great. That does not mean I did not complain about them with my fellow developers from time to time 🙂

It does mean however that I understood that if we were going in the right direction, if we were delivering features at an high speed and if we were able to coordinate our projects with the rest of the company it was because of their work.

So I am very convinced that PMs can make a difference. But this difference can be either atrociously negative or wonderfully positive. I am not saying I understand all the responsibilities of a PM and I am sure there is a lot of things they do without interacting with developers like me. I am just thinking specifically to how PMs interact with developers and what kind of expectations I have as a developer towards PMs.

From my point of view a Project manager could make the life of developers easier by doing these five things.

1. Communicate business priorities and consider technical priorities

We are all over-worked and we all have crazy piles of work who someone expects us to do within the week. As a developer I need to be able to evaluate the effort needed to complete each task and the relations between tasks. Perhaps a certain refactoring will simplify developing a certain feature, so it makes sense to order those tasks accordingly. A certain task could take two weeks, while implementing these three other features could require just half a day for each of them. So I could prefer to work on them first.

But technical aspects are just half of the picture: ordering tasks require us to be aware of the priorities business have. What is most important for the customer? Which features can have an immediate impact on our revenues? That is very important for us to know to decide where to spend our energy and what to deliver first. I think PMs need to discuss frequently with developers what are the priorities and understand that business priorities and technical priorities need both to be considered to decide on what we are going to work next.

And sometimes PMs technical priorities are important too: they cannot always be ignored to consider only business priorities, because doing so it is going to affect our ability to deliver software and consequently the business.

2.Technical Project Managers Should Let the developers know about deadlines well in advance.

Did ever happen to you to find out that something is needed… later today? Or that the customer was promised to receive a new build yesterday? Those are not nice surprises. Let’s be clear: sh*t happens and require us to deal with it. The application goes down and the company loses money every minute: you stop whatever you are doing and you fix it. A new bug is found and it is bad, a security concern needs to addressed as soon as possible. In real life there are things that we cannot plan for. We can just react to them.

However this cannot be the case for everything, we cannot always be doing Emergency-driven development. This is just bad practice. Deadlines need to be agreed upon and communicated, so that they can be planned for. As developers we frequently do not see the whole picture but the same goes for Technical Project Managers: there are technical aspects that they could be ignoring and that could make not possible to meet a deadline, without knowing far in advance. So please dear Technical Project Managers: let us know about deadlines as soon as you know them.

Caveat: when I say “let the developers know about deadlines” I mean the real deadlines. One of the worst thing a Technical Project Managers could ever do is to present some fake, self-imposed deadline. Some Technical Project Managers came up with the idea of assuring themselves a time buffer by telling the developers that the customer expects the delivery to happen on the 1st when they actually agreed on the 15th. Maybe they do that because we frequently deliver things late but… guess what? Sooner or later developers will find out and think about all the useless stress or the long hours they went through because of your lies. How do you think they are going to react?

3. Manage communications properly

I know it could sound not plausible but developers tend to have a few defects. One of them is that developers tend to communicate… differently. They tend to be direct and blunt. And that works great with machines, a bit less with customers. Yes, it is possible that the SDK the customer given to you seems… suboptimal. Yes, it could seems a perfect example of what a bunch of monkeys could do if we would give them a box of cheap whiskey and a manual of all the possible bad practices in software engineering. Well, still it is not a good idea to let the customer knows about that. It is much better to let the PMs rephrase that for us.

And I love when the PMs chase the customer about that decision we need him to make. Or talk with the PM of another team to convince them to answer to the requests from our team. Yes, we really needed an answer, all the three times we forwarded again the same requests that was ignored for the last couple of weeks.

A fantastic PM will provide us with all the information we need to do our job and ensure communication run smoothly with all the parties involved. We probably will not even realize the effort he had to put on this.

4. Leverage Effort To Shield developers from issues

Life in a company is stressful. Stress comes from different sources and it needs to be managed. As Software Developers we deal with a lot of stress coming from technical challenges: a bug which is very difficult to reproduce, an intermittent issue depending on threads synchronization, the new release of a framework which silently breaks everything, an unreliable piece of infrastructure that makes some integration test to fail. We have plenty of reasons to be stressed.

And Project Managers have too: they deal more than us with the internal politics, they take part in discussions about what features to develop and which not, they could fight to get resources for the team. They could compete with other teams, they have customers screaming at them. Well I am sorry for that but if PMs start to push all their stress on the developers, then we, the developers, will end up being between the anvil and the hammer. We would be both constrained by the reality of technical difficulties and the pink-pony-crazyness of customers and politics. That is just too much so let’s have a deal: we stress with technical stuff and that is our burden. All the rest, I am sorry for you PMs, but this is for you to deal with.

5. Make sure we work on specific relevant projects

It could happen to work very, very hard on building something that has a very limited impact on the company product. While it could be a satisfaction anyway for someone who loves to build cool stuff in the long run this is going to be detrimental for your career. It does not help you getting a promotion if you keep working only on irrelevant stuff. Working on something that can really make a difference for the business have several advantages instead: it gives you additional motivation, the possibility to get noticed and possibly access to more resources and more support from the organization.

Working on irrelevant features is not yet the worst thing that could happen. It could happen to work on projects that are discarded before or immediately after they are completed. Imagine put your passion and sweat on something that is just thrown away. Not a nice feeling, eh? So it is better to work with PMs who do not put you in such situations.

In the end I think Project Managers intercept many problems before we can even see them. They are our interface with the customers and with the rest of the organization. They ensure we are working on something which will provide value to our users. They keep track of the whole picture so that we can have the luxury to just focus on the next feature to implement, test it and ship it. And it is a fact that developers take PMs for granted most of the time. I think it is pretty common for developers to underestimate PMs. We often just do not understand all their responsibilities. But trust me, if you work with a great PM and a… not so great one, you will definitely notice the difference.

I hope both us developers and project managers can benefit from a better relationship. I can tell you it is possible to do so: I live with a PM who my girlfriend.

 

The post 5 Tricks required to be a Superior Technical Project Manager. Amazing!!!. appeared first on Henning Kristensen Product Development.

]]>

To be effective as a Techical Project Manager, technical excellence is not enough. On top of that there are several other aspects on which a great professional should focus. Near the top of my list there is the ability to interact with other people involved in the project. Whatever is the nature of your project you will need to interact to get things done :

  • as an open-source contributor you have to collaborate reviewing patches or having your patches reviewed, you have to address the issues brought up by users, you want to communicate your features to new users, planning with other committers or co-maintainers
  • as a freelance you have to interact with the current customers and with potential ones. You have also to interact with other developers or designers or testers involved in the projects and you need to communicate clearly who is responsible for what
  • when working in a company you have to coordinate with the other developers, in your team and in other teams, to communicate with your manager and most importantly to interact with project managers

Developers and PMs… not always love at first sight

Relationships with the Project Managers can be a bit controversial from time to time: we as developers are very prone to complain about them. After all, they are the ones bothering us about some change that needs to go in at 6 PM on a Friday. Or the ones who keep pushing for features which do not make sense to us.

However, I think that Project Managers play a fundamental role in successful team. And as a developer i can be successful only if the team is successful. For this reason, I think that having a great relationship with Project Managers is they key for delivering results. I was lucky enough to work with amazing Project Managers that really helped me. This was especially true when I was at TripAdvisor: there I met PMs who were absolutely great. That does not mean I did not complain about them with my fellow developers from time to time 🙂

It does mean however that I understood that if we were going in the right direction, if we were delivering features at an high speed and if we were able to coordinate our projects with the rest of the company it was because of their work.

So I am very convinced that PMs can make a difference. But this difference can be either atrociously negative or wonderfully positive. I am not saying I understand all the responsibilities of a PM and I am sure there is a lot of things they do without interacting with developers like me. I am just thinking specifically to how PMs interact with developers and what kind of expectations I have as a developer towards PMs.

From my point of view a Project manager could make the life of developers easier by doing these five things.

1. Communicate business priorities and consider technical priorities

We are all over-worked and we all have crazy piles of work who someone expects us to do within the week. As a developer I need to be able to evaluate the effort needed to complete each task and the relations between tasks. Perhaps a certain refactoring will simplify developing a certain feature, so it makes sense to order those tasks accordingly. A certain task could take two weeks, while implementing these three other features could require just half a day for each of them. So I could prefer to work on them first.

But technical aspects are just half of the picture: ordering tasks require us to be aware of the priorities business have. What is most important for the customer? Which features can have an immediate impact on our revenues? That is very important for us to know to decide where to spend our energy and what to deliver first. I think PMs need to discuss frequently with developers what are the priorities and understand that business priorities and technical priorities need both to be considered to decide on what we are going to work next.

And sometimes PMs technical priorities are important too: they cannot always be ignored to consider only business priorities, because doing so it is going to affect our ability to deliver software and consequently the business.

2.Technical Project Managers Should Let the developers know about deadlines well in advance.

Did ever happen to you to find out that something is needed… later today? Or that the customer was promised to receive a new build yesterday? Those are not nice surprises. Let’s be clear: sh*t happens and require us to deal with it. The application goes down and the company loses money every minute: you stop whatever you are doing and you fix it. A new bug is found and it is bad, a security concern needs to addressed as soon as possible. In real life there are things that we cannot plan for. We can just react to them.

However this cannot be the case for everything, we cannot always be doing Emergency-driven development. This is just bad practice. Deadlines need to be agreed upon and communicated, so that they can be planned for. As developers we frequently do not see the whole picture but the same goes for Technical Project Managers: there are technical aspects that they could be ignoring and that could make not possible to meet a deadline, without knowing far in advance. So please dear Technical Project Managers: let us know about deadlines as soon as you know them.

Caveat: when I say “let the developers know about deadlines” I mean the real deadlines. One of the worst thing a Technical Project Managers could ever do is to present some fake, self-imposed deadline. Some Technical Project Managers came up with the idea of assuring themselves a time buffer by telling the developers that the customer expects the delivery to happen on the 1st when they actually agreed on the 15th. Maybe they do that because we frequently deliver things late but… guess what? Sooner or later developers will find out and think about all the useless stress or the long hours they went through because of your lies. How do you think they are going to react?

3. Manage communications properly

I know it could sound not plausible but developers tend to have a few defects. One of them is that developers tend to communicate… differently. They tend to be direct and blunt. And that works great with machines, a bit less with customers. Yes, it is possible that the SDK the customer given to you seems… suboptimal. Yes, it could seems a perfect example of what a bunch of monkeys could do if we would give them a box of cheap whiskey and a manual of all the possible bad practices in software engineering. Well, still it is not a good idea to let the customer knows about that. It is much better to let the PMs rephrase that for us.

And I love when the PMs chase the customer about that decision we need him to make. Or talk with the PM of another team to convince them to answer to the requests from our team. Yes, we really needed an answer, all the three times we forwarded again the same requests that was ignored for the last couple of weeks.

A fantastic PM will provide us with all the information we need to do our job and ensure communication run smoothly with all the parties involved. We probably will not even realize the effort he had to put on this.

4. Leverage Effort To Shield developers from issues

Life in a company is stressful. Stress comes from different sources and it needs to be managed. As Software Developers we deal with a lot of stress coming from technical challenges: a bug which is very difficult to reproduce, an intermittent issue depending on threads synchronization, the new release of a framework which silently breaks everything, an unreliable piece of infrastructure that makes some integration test to fail. We have plenty of reasons to be stressed.

And Project Managers have too: they deal more than us with the internal politics, they take part in discussions about what features to develop and which not, they could fight to get resources for the team. They could compete with other teams, they have customers screaming at them. Well I am sorry for that but if PMs start to push all their stress on the developers, then we, the developers, will end up being between the anvil and the hammer. We would be both constrained by the reality of technical difficulties and the pink-pony-crazyness of customers and politics. That is just too much so let’s have a deal: we stress with technical stuff and that is our burden. All the rest, I am sorry for you PMs, but this is for you to deal with.

5. Make sure we work on specific relevant projects

It could happen to work very, very hard on building something that has a very limited impact on the company product. While it could be a satisfaction anyway for someone who loves to build cool stuff in the long run this is going to be detrimental for your career. It does not help you getting a promotion if you keep working only on irrelevant stuff. Working on something that can really make a difference for the business have several advantages instead: it gives you additional motivation, the possibility to get noticed and possibly access to more resources and more support from the organization.

Working on irrelevant features is not yet the worst thing that could happen. It could happen to work on projects that are discarded before or immediately after they are completed. Imagine put your passion and sweat on something that is just thrown away. Not a nice feeling, eh? So it is better to work with PMs who do not put you in such situations.

In the end I think Project Managers intercept many problems before we can even see them. They are our interface with the customers and with the rest of the organization. They ensure we are working on something which will provide value to our users. They keep track of the whole picture so that we can have the luxury to just focus on the next feature to implement, test it and ship it. And it is a fact that developers take PMs for granted most of the time. I think it is pretty common for developers to underestimate PMs. We often just do not understand all their responsibilities. But trust me, if you work with a great PM and a… not so great one, you will definitely notice the difference.

I hope both us developers and project managers can benefit from a better relationship. I can tell you it is possible to do so: I live with a PM who my girlfriend.

 

The post 5 Tricks required to be a Superior Technical Project Manager. Amazing!!!. appeared first on Henning Kristensen Product Development.

]]> http://henningkristensen.com/5-things-takes-superior-technical-project-manager/feed/ 3 5932