I think most of you will agree when I say:

Building amazing products is pretty darn hard.

Why?

Because getting insights into what your customers want is not an easy task.

But, there is help!

Today, you will learn how to use five digital tools to gain valuable customer insights. 

Insights that will help you to build products your customers love.

Here are the tools we will be looking closer at:

  • Google Analytics – The old trusty GA can actually be useful
  • Google Optimize – The new kid on the block, making A/B testing looking easy
  • Hotjar – Getting hot insights with their heatmaps
  • Teston – Video killed the data-driven stars
  • Don’t hesitate – Not really a tool, but nevertheless a very important mindset

For each tool you will learn about important features, how you can use it and a few examples I did with a site called Bilkjop (used car portal).

Google Analytics

I will start off with showing you how GA (Google Analytics) can be used.

I will assume that you have some prior knowledge of GA.

Most of you probably use GA out of the box, without any customization. Maybe you didn’t even know it was possible to customize GA. 

But, it certainly is, and I encourage you to do so.

We will now dig deeper into three features of GA, that will help you gain customer insights and make GA a valuable tool in a customer-driven product development environment.

  • Goals
  • Segments
  • Events

There are of course a lot more useful stuff inside GA, but I feel these three are a good starting point.

Goals

One of the first steps is to set up goals in GA properly.

Now, in order to setup goals, you first need to think hard about what you want to measure.

What are good indicators of customer engagement? A submitted form? Time spent using your product? Clicking on email links?

There are countless different events you could measure.

These goals will be the foundation to measure if changes to your product were helpful or not.

Here I will share with you my four goals I used for Bilkjop.

Number of booked test drives

The primary target of the product is to sell more used cars.

The obvious first though is to enable a buying option on the website.

And, eventually, we will get there.

But, for now, we use the option to collect hot leads from the website by allowing them to book a test drive at the dealer ship.

This is the primary goal, and we measure it closely by tracking each step of the checkout funnel.

All the features on the website are in one way or another connected to this goal.

So, when I talk about customer-driven product development, it is to gain insights into what the customers want from a used cars website to complete our end goal – sell more cars.

Number of financial leads

The second goal we measure is how many leads we generate for our financial services. It is nothing fancy, just measuring how many clicks we have on a specific button. But, it is nonetheless an important goal, since the value of securing a car loan deal with our customers is high.

Users who visited at least one car

To even be able to book a test drive, a visit to a car page it a prerequisite. Therefore, we measure the users who visited at least one car.

Users who visited more than five cars

For most people, visiting just one car isn’t enough for us to find the right fit. Potential car buyers usually check several different options. Therefore, we measure the users who visit more than five different cars.

So, there you have it, the four goals we measure for Bilkjop.

But, wait?

Isn’t this merely reporting on numbers? How does this help me gain customer insights and find out what they want?

It will help you in two ways:

  1. You can use these goals to see how your product increments affect them
  2. You can use them together with segments

And lo and behold, next topic is about segments!

Segments

Segments is sadly an often ignored and overlooked feature of GA. Even though it is pretty “in-your-face” on almost all reports. Yeah, it’s that top bar saying “All Users”.

So, why is it so often ignored and how can you use it?

It isn’t ignored all that much if we think about it. Because when you look at how a specific traffic source behaves, you have already segmented your traffic. The thing I am coming to is that there are so much more to segments, other than traffic sources. And those segments are often overlooked.

GA comes with a pretty neat list of system generated segments. Now, the deal with segments is to compare them and see how the perform against each other.

For example:

  • Does mobile traffic convert better or worse than desktop traffic? 
  • Does user who did a search visit more pages than those who don’t?

By asking yourself questions like these and analyzing the answers, you will find room for improvements. If, for example, the users who searched visited more pages (and if that is important to you) you should consider encouraging more users to search. You can do so by tweaking the search design, function and location of the search bar, and thus potentially increase the number of users who search.

To go even deeper with segments, you can create your own. A good start is to create a segment for each goal you have.

In my example, I created a segment for each goal. Then I can analyze what the converting traffic for each goal does differently than the non-converters. 

I have also created segments for different traffic sources grouped together. This way I can easily compare different traffic sources, in a way that is meaningful for me.

So, the basic idea behind segments is to use the default, create custom ones and compare them against each other. Based on that you will have to get creative and think why they differ and if there is something you can do about it.

When you have implemented something new, you can track the effects by looking at your goals data.

Events

One of the most powerful and useful features of GA is the use of custom events. Hey, they even created Google Tag Manager with custom events in mind. 

Events are custom information snippets sent to GA when your users do something in your product that you have specified. 

A most basic example could be that when users click a specific button, we can send that button name as an event to GA. You can then use this event and connect it to a goal.

A more advanced example is shown below.

Here we track click on each step in the checkout funnel for a test drive.

And here we track the requested time for the test drives.

As you can see, we can derive any type of information from the customer’s behavior by using custom events. And with GTM (Google Tag Manager) we can do quite a lot without involving programming resources. There are even packages you can install to GTM, where you get a lot of useful events out of the box.

So, as you can see, there is a lot of power in this feature and only your imagination sets the limit on the data you can create with custom events.

There you have it.

Three areas in GA that you can use to understand your customers better. Now, we will move on to another tool from Google and see how it can be used to create products that your customers love.

Google Optimize

Next up is the A/B testing tool Optimize from Google. With this tool, you can easily create A/B test on your website.

As with all Google tools they are tightly integrated with each other. And, there is no difference between Optimize, it is nicely integrated into Google Analytics.

With that integration and a straightforward interface to create A/B test, this tool is one of my favorites.

If you don’t know what an A/B test, it is when you test two different variant and compare them against a given target.

Let me show you two examples that we did with bilkjop.no

Text on CTA button

In our first example, we made an elementary test, two different texts on a CTA button. 

Avtal visning VS Booke prøvekjøring (Two variants of saying “Book test drive”). We measured which one of these who generated the most button clicks.

So, what do you think? Which on performed better? Was there a clear winner?

Well, here are the results.

Now, what can we learn from this?

As we see, there was no clear winner. So we can learn that just changing texts and colors on CTA buttons probably won’t have any significant difference. 

Many argue that to get real results we need to dig deeper into our visitor’s psychology and find out what their real pain is and how our product can address those. And, this is not simply done by changing word or two on a button.

Nevertheless, let’s have a look at another A/B test with drastically different results.

We wanted to test if choosing date and time for a test drive, and then enter your contact details converted better then the other way around.

What do you think? 

Our theory was that it would convert better, since choosing date and time is a lesser commitment than entering your contact details first. And once your are “in-the-funnel”, you will continue, highly inspired by the microtransaction concept.

And guess what?!

Here we have a clear winner – presenting the calendar first is without a doubt the better performer.

Entirely different results than our CTA button text A/B test!

What are our takeaways form these results?

You will probably not find a clear winner by testing small changes like colors and texts. It seems to be better to test more extensive changes to your landing pages.

Think deep, and do customer interviews to find out what your customer’s pain points are and try to address them with a new design.

And test that new design against your old one.

Then you surely will see a clear winner instead of tweaking small things.

Hotjar

Hotjar is a tool for creating Heatmaps.

So, what are heatmaps and what are they good for?

Heatmaps tracks where your visitors interact on your website. 

This can be good since you will learn what parts of your website are the most interesting for you visitors. 

By using this information, you can rearrange or promote certain elements more or less depending on how much they are interacted with. You can generate heatmaps based on clicks, mouse movement and scrolling. 

Here we have our move Heatmap. 

These are some insights we can learn from this:

– The pagination links at the bottom are very popular. Maybe we should replace them with endless scroll.

– The sorting options are much used. Since this is obviously something our users want, we should make sure they are as good as they can get.

– The search bar is not that popular. We could replace it with something our users would rather have in that prominent spot.

– The filter “Forhandler” is popular, should be moved up.

– The filter “Karosseri” is not popular, should be moved down.

– The favorite function are also popular and should stay where it is.

In addition to Heatmaps, Hotjar offers a few other features. Here are the ones I believe are useful:

Polls: You can easily create a poll and implement on your website.

Recruiter: You can implement a popup form on your website asking for persons who are interested in testing your site. This feature can play very well together with Teston for video and screen share testing. You will learn more about Teston next.

Teston

So far, we have used data to interpret how our visitors use and think of our products. This is all very useful, but there is one information source then beats all that. 

And that is.. drumroll… observing people and listening to their thoughts as the use your product.

This has traditionally been a quite complex, costly and time-consuming activity.

But, there are now options to digitalize this process as well. 

We used a service called Teston where we can get videos of actual people and their screen when using our products.

It is all digital and works like this:

  1. Create a list of activities and question you want the test person to do and answer
  2. Actual people will do your test and record themselves and their screen
  3. Watch the videos and gain customer insights

And the result will look something like this. Here we see the tester’s screen and face. The numbers in the button bar are the shortcuts to the activities/questions in our test script.

My experience with this kind of testing is outstanding. Of course, it depends on the persons doing the test, but the quality was excellent for all the testers I got.

Watching actual usage of the services helps to identify pain points and improvement to the product.

One example was the price slider, which was not very user-friendly when searching for lower priced cars accordingly to our testers. They had problems specifying the from and to price by just using the slider. And when the from and to price were close, the two round slider indicators became one.

From this, we learned that we should improve it to allow the user the enter a from and to price manually.

Don’t hesitate

“Don’t hesitate” it not a tool, but an essential mindset that you should embrace to realize all the things you will learn from the tools we have discussed.

You must not be afraid to test new ideas and concept based on the customer insights you gain.

This will lead to some successes, but also some failures.

Don’t be afraid of that.

Instead, keep track of your data, test new ideas quickly and evaluate. And, if they don’t work, go back to what you had, or try something else. Keep trying, and eventually, you will find something that your customers love.

By adopting an agile framework like Scrum or Kanban, you will enable a setup that allows for failing fast. The basic theory is to come up with an idea, plan it, develop it and release it. Then keep tracking your data to see the results.

How do you become a better project manager?

It is not an easy question to answer.

One way is to read books and learn more about the profession.

But, which books are the best and worthy of your time?

Today, I will show you my top 19 project management books that will help you expand your knowledge and become exceptionally valuable to yourself and your clients.

This list might not be like your average project management book list. Rather than focusing on project approaches, principles and methodologies – these books will teach you the more softer and interpersonal skills required to excel as a project manager and move to the next level.

I have made no ranking between the books since they all cater different skill areas and a comparison between them would make no sense.


The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win

The Phoenix Project is written by Gene Kim, Kevin Behr and George Spafford was published in 2013.

The book is written like a novel and tells the story of Bill Palmer, an IT manager at Parts Unlimited. One Tuesday morning Bill receives a call from the CEO of the company and he wants him to take charge of a critical project called “The Phoenix Project”.

Bill reluctantly accepts the task and we will then follow Bill’s journey throughout the project. During this journey Bill will encounter a lot of difficulties and problems, many that will make you smiley in resemblance.

But, as you can imagine, after changing the methods and culture within the company, Bill manages to make the project a success.

The book is quite helpful for project managers since it will give you insights, methods and an overview of how improvements can be made to better execute IT projects. If not, it will at least tell you an interesting story spiced with a great deal of humor.

The book is already somewhat a classic within the IT world and considered a “must-read” for IT-professionals.


Smarter Faster Better: The Secrets of Being Productive in Life and Business

Smarter Faster Better is written by Charles Duhigg and was published in 2016.

Duhigg is a Pulitzer-Prize winning reporter from The New York Times. With this background one would expect a well written piece – and he doesn’t let you down in that regard.  

The book is made up of a few stories promoting different concept that promises you to become more productive and effective if life and business.

While the ideas are not bad, they are not really new either. However, since they are complemented with engaging storytelling this makes the book an easy and interesting read.

Overall, Charles promises to help you become better in these areas:

  • Motivation
  • Teams
  • Focus
  • Goal setting
  • Managing others
  • Decision making
  • Innovation
  • Absorbing data

As a project manager the ideas can help you, as claimed by Charles, to become more productive and more effective. But, bare in mind it is a long read for a few concept which could be gathered elsewhere in a less time-consuming fashion.


Running Lean: Iterate from Plan A to a Plan That Works

Running Lean is written by Ash Maurya and the first edition of the book was published in 2012.

Ash is truly living as he learns. Ash didn’t just write the book directly, rather he began the book process by publishing various articles on his blog. He later turned those articles into a book using the methods and principle he preach.

The book will give you a blueprint for achieving a “product/market fit” for your venture. He claims this strategy could be used on any idea you have but they are primarily for IT adventures.

I’d highly recommend you to try, if not all, but some of the strategies, methods and techniques in your next project. This is about as agile/lean as you can get.

The basic ideas are nothing revolutionary, but Ash manages to put it all together with practical and helpful techniques.

You will probably find yourself coming back to the book when you need guidance and advice running lean projects.


Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition

Coaching Agile Teams is written by Lyssa Adkins and was published in 2010.

In this book Lyssa guides the reader to what it takes to become an agile coach and the different paths one could choose to achieve that.

Lyssa holds nothing back and the book is full with tips and tricks for the different roles and scenarios you might end up in as an agile coach.

You will get information on a quite detailed level like exact questions to use and how to act as an agile coach – this is all very useful and practical.

The famous agile master Mike Cohn seems to have been quite involved before and during the writings of the book, this gives the rather unknown author extra credibility.

As a project manager this book will help you take your career to the next step and embrace the role as an agile coach.


TED Talks: The Official TED Guide to Public Speaking

TED Talks is written by the TED Talks curator Chris Anderson and was published in 2016.

The speakers at TED events are generally considered to be the best in the world. The talks generates millions of views and likes.

It would then seem like a pretty good idea to learn from speakers to learn what makes them so interesting. This is exactly what Chris Anderson has done and put together in this book.

Chris has been working with TED since 2001 and helped their speakers to perform at their best.

The book covers the following topics:

  • Foundations
  • Talk tools
  • Preparation process
  • On stage

As a project manager you will end up speaking to people in both formal and informal settings. Therefore, this book is really helpful in order to improve your techniques and perform better at presentations, talks etc.


Getting to Yes: Negotiating Agreement Without Giving In

Getting to Yes is written by Roger Fisher, William L. Ury and Bruce Patton. The edition reviewed here was published in 2011, although the first version was published back in 1983.

Since this book has been around for such a long time it has gathered a lot of fans and is considered a classic “must-read” within the negotiation genre.

The book promises you to learn:

  1. Disentangle the people from the problem
  2. Focus on interests, not positions
  3. Work together to find create and fair options
  4. Negotiate successfully with anybody at any level

As a project manager you can never learn to much about negotiations and conflict resolutions. Therefore, this book can really help you become a better project manager.


So Good They Can’t Ignore You: Why Skills Trump Passion in the Quest for Work You Love

So Good They Can’t Ignore You is written by Cal Newport and published in 2012.

Cal doesn’t give much for the saying “follow your passion”. Passion is not predetermined, but rather the results of being really good at something.

Accordingly to Cal you should focus on becoming a master of your craft, and only then you will experience what we call passion.

This mindset is really useful to remember when you are experience rough times in your work life. When you do, remember that changing to another professional that you have a “passion” for might not be the solution.

Rather, you should focus on getting better at your craft, learn from your mistakes and not give up.

As a project manager that would equal to educate yourself and continuously learn new stuff to excel in your field. By doing this you will get better and better and as a results, your passion for project management will increase.


Influencer: The New Science of Leading Change

Influencer is written by Joseph Grenny, Kerry Patterson, David Maxfield, Ron McMillan and Al Switzler and was published in 2013.

The authors behind this book represents a great deal of knowledge and experience, and they have published many other books under their brand VitalSmarts.

Influencer will give you the tools and techniques in order to excel in the field of change and behavioral management. The knowledge can be either applied on a team or personal level.

After reading this book it will become quite clear the change doesn’t come by accident, but it is the results of careful diagnosis, “patient” testing and eventually success will follow.

The book is highly relevant for project managers since all projects bring change. And it is up to the project manager to prepare and allow people to embrace this change with a positive attitude.

After reading and absorbing the thoughts from this book you will be much better prepared.


Never Split the Difference: Negotiating As If Your Life Depended On It

Never Split the Difference is written by Chris Voss and published in 2016.

Negotiating is a crucial project management skill in order to deal and make progress with all different stakeholders.

Therefore, Chris comes to the rescue with his latest book Never Split The Difference.

The former FBI hostage negotiator has written an engaging book where he teaches his wisdom regarding negotiation.

One could argue that the scenarios where Chris learned and applied his techniques are so far off from the situations of a project manager. But, in the end we are all human beings and negotiating is really about human psychology which can be applied regardless of the situation.

As many other authors Chris enforces his ideas with real life stories. This makes it easier to remember and read.

The main ideas are:

  1. Be a mirror
  2. Don’t feel their pain, label it
  3. Beware Yes – master No
  4. Trigger words
  5. Bend their reality
  6. Create the illusion of control
  7. Guarantee execution
  8. Bargain hard

Influence: The Psychology of Persuasion

Influence is written by Robert B. Cialdini and was published in 2006.

This book has been around for a while, the first edition was published back in 1984. But, the ideas, which are based on human psychology, are still as relevant now as then.

You have probably heard or experienced the six main ideas in one form or another already:

  • Reciprocation
  • Commitment
  • Social Proof
  • Liking
  • Authority
  • Scarcity

These concepts are not new, but they are very well described and filled with references to scientific studies and real life stories.

This makes you really understand and remember the ideas so that you can start using them in your life and business.

As a project manager you will often find yourself in the position of persuasions and negotiations with client and other team members. And when you do, you will be glad that you read this book.


Crucial Conversations Tools for Talking When Stakes Are High

Crucial Conversations is authored by Kerry Patterson, Joseph Grenny, Ron McMillan and Al Switzler from Crucial Skills and was published in 2011 (second edition).

If you are a person that doesn’t like to take the difficult conversions this book is for you.

The authors has put together a nice piece that promise to:

  • Prepare for high-stakes situations
  • Transform anger and hurt feelings into powerful dialogue
  • Make it safe to talk about almost anything
  • Be persuasive, not abrasive

There are a lot of scenario in projects that can lead to crucial conversations. Avoiding them seldom solves anything, except the temporarily relief of putting of a problem to another day.

Therefore, this book comes in handy to give you the knowledge and tools to master these type of conversations.

I know from experience that it is much better to take the crucial conversation rather than to avoid it. And this book will help you to do just that.


Hooked: How to Build Habit-Forming Products

Hooked is written by Nir Eyal and published in 2014.

This might seem to be an odd choice for a list of project management books. However, Nir has written a must-read book in order to understand how some products become successful and some not.

Big surprise – it is mostly driven by getting us hooked on your product.

But, how you do build a product that make the users come back for more many times per day?

Well, you use these four techniques:

  1. Trigger use of the product
  2. Use call to actions
  3. Give the user variable rewards
  4. Make the user invest in your product

The book will give you a lot of eye openers in how easily you are triggered to use certain apps like Facebook or LinkedIn – they all use these techniques.

As a project manager you can use these techniques in order to make products more used, more loved and more addictive.


Power Questions: Build Relationships, Win New Business, and Influence Others

Power Questions is written by Andrew Sobel and Jerold Panas and was published in 2012.

Another book on on the same topic , “The Coaching Habit”, gives us 7 powerful questions. In this book Andrew and Jerold has put together 337!

The have grouped the question together for different situations like holding a meeting, discussing a proposal and so on.

Since there are so many question is can be hard to remember them all, so this book works rather like a guide that you can pick up just before you enter one of the situations described.

As a project manager many of these questions are highly relevant when building relationships and making deals with project stakeholders and customers.


Lean Enterprise: How High Performance Organizations Innovate at Scale

Lean Enterprise is written by Jez Humble, Joanne Molesky and Barry O’Reilly and was published in 2015.

Lean Enterprise is about doing lean/agile within bigger companies. For smaller startups it comes naturally and they strive in an innovative setting.

However, large enterprises are often controlled and structured in a way that makes going lean difficult. An example of this is described in the book “The Phoenix Project” (also on this list) where an large organization turns the tides from not so much lean to very lean.

If you also want to make this change, then this book if you for. It will give you practical advice how to change your organization or project to being more lean within a large enterprise.

The book has become somewhat an authoritative reference for how large enterprises can embrace and become lean.


Deep Work: Rules for Focused Success in a Distracted World

Deep Work is written by Cal Newport and was published in 2016.

Cal is the youngest author who made it to this list. However, his idea are in clear contrast to what most of today’s youth are doing.

“Deep Work is the ability to focus without distraction on a cognitively demanding task.”

With that statement Cal claims that the most important skill you should develop is the ability to do deep work. Most of today’s workforce are spending their time with shallow activities which contributes little or no value.

Why?

Deep work is tough and requires both effort and training. The basic concept is to set aside a time slot which is 100% dedicated to a demanding, not shallow, task. Remove all distractions and focus purely on your task.

This book and concept is really useful to understand and apply for project managers. If your team members are working on demanding tasks – make sure they can fully focus on the task and do not let any distractions get in their way.


Leaders Eat Last: Why Some Teams Pull Together and Others Don’t

Leaders Eat Last is written by Simon Sinek and was published in 2014.

In his book Simon digs deeper into why some team works some why some don’t. The main idea is that higher performing teams have a deep sense of security and trust among the team members, while poor performing teams does not.

Simon also explains how this can be achieved with a focusing on the behavior and attitude from the team leader. The ideas are complemented with true stories from the military and corporate sector.

Understanding how and why some teams outperform others is a crucial knowledge for every project manager. That is why books like these should be must reads for all persons serious about getting good at project management.


Start with Why: How Great Leaders Inspire Everyone to Take Action

Start with Why is written by Simon Sinek and was published in 2011.

Why do you read this article of project management books?

If you don’t know the answer to that question, then you should read this book.

Simon begins the book with telling us the whole idea started with he asking himself why did he do what he did. He struggled to find meaning and purpose in life and business.

So, in this book he explains the importance of knowing why you do what you do and how to discover your own why.

This skill and mindset of understanding the why is very useful and a must to apply in project teams. If you can get each and every team member to identify their own why, your team will be one step closer to becoming a truly high performing team.


The Coaching Habit: Say Less, Ask More & Change the Way You Lead Forever

The Coaching Habit is written by Michael Bungay Stanier and was published in 2016.

This little gem is a short and quick read. Michael has done a great job with keeping it fun and easy to read – yet the content is super practical and helpful.

Basically, Michael gives you 7 different questions to use when talking to or coaching others.

  1. What’s on your mind?
  2. And what else?
  3. What’s the real challenge here for you?
  4. What do you want?
  5. How can I help?
  6. If you’re saying yes to this, what are you saying no to?
  7. What was most useful for you?

You don’t have to be a rocket scientist to learn these. But, you do need some context and practice to use them wisely together. And it is only then, when used together, these questions really becomes a powerful tool when you need to coach someone.

For project managers these questions are amazing. They will be the backbone of your one-on-one with different team members and help you to really dig down and help the other person identify and deal with their problems.


Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days

Sprint is written by Jake Knapp, John Zeratsky and Braden Kowitz and was published in 2016.

What if you only had one week to test and prove an idea?

No problem! At least not after you have read this book.

The three authors all have a background from Google Ventures, and it was there, during hundreds of sprints they developed the method described in the book.

The idea is that you put together a team working 100% for five days (monday-friday) developing and trying out an idea to see if it has the potential to be successful or not.

By doing this as a first step you drastically reduce the risk of committing more fully to the idea.

For project managers this approach can be really useful when working in a project which require the team to be innovative and come up with new ideas.

Do you always delivery 100% successful IT project?

Then you are doing something wrong!

Here is why:

A very important part in any project is to find what worked well and what could be improved, in other words, identify the lessons learned. If you feel that there is nothing that can’t be improved for your next project you are on a downhill battle.

If you don’t move forward, you are moving backwards.

In this article I will share with you 17 of the most important lessons learned you can take as an IT project manager.

  1. Requirements, requirements and more requirements

Bright man writing down requirements.

Bright man writing down requirements.

Unfortunately, it is quite common that IT project starts like this:

Some very bright men and women sit down together and begin to write down all of the requirements that they can think of for the new software/system that that are so eager to see developed.

But, what do you think usually happens with this approach when the project is coming to an end?

One, or a combination, of these three outcomes usually happens:

  1. The end results are lacking a lot of the defined functionality
  2. The need from the users have changed
  3. Everything is developed accordingly to the requirements and the needs has not been changed.

In all honesty, the first two outcomes are much more likely to happen than the third.

Let me tell you why:

Writing down all the functionality for a software/system and then leave everything to the developers until they say it’s ready for testing is generally a bad idea.

With that approach you have no possibility to verify that you are on the right track, make changes or come up with different, better functionalities until everything is ready.

Instead, you should focus on specifying just enough to keep your team to be busy for 2-4 weeks.

When those weeks have passed you should be able to test and review what has been developed.

After that you can define changes to what has been developed or new functionality that you want in the coming 2-4 weeks.

By implementing a project in short iterations of 2-4 weeks you will have a much more agile approach, which in the end will increase the likelihood of your project to be successful.

My Lesson Learned

I once joined a project as the project manager for the final development phase of a new IT system.

There, I discovered that some of the specifications were 4-5 years old, and still had not been developed and approved.

This caused a lot of frustration for both the customer and the supplier.

Here is how I solved it:

We started to follow the suppliers sprint plan, which meant defining what functions that should be developed every two weeks.

After each iteration we had the possibility to test and make changes to the functionality. We also released some of that functionality to the live environment once per month.

By implementing this agile approach we didn’t have to worry about those old specifications. The new specifications came in regularly to the backlog, were prioritized, developed and released.

  1. Tərcümə , tərcümə və daha çox tərcümələr

That's not quite right.

That’s not quite right.

What?!

Yes, that is what a lot of customers are saying when they review a product.

I’m talking about lost in translation issues.

Since some developers don’t speak the same language as the end users there might be some text in the software that weren’t translated correctly, or not even translated at all.

This is a minor issue, but can cause unnecessary discussions.

To avoid this, the supplier must take greater care and put in place routines for verifying that all text that should be translated is.

Ideally, the project should install a role which has the responsibility to verify all translations.

That roles responsibility should also include the task to define what common terms really mean, and also how to spell it so that everything looks the same throughout the software.

  1. Let’s agree to disagree

Let's agree to disagree.

Let’s agree to disagree.

There are usually many stakeholders involved in IT projects, and everyone has their own opinion on how things should work.

That means that whenever there is new functionality to be specified, you have to talk with all involved and relevant stakeholders and come to an agreement.

When you have set up a meeting to discuss the new functionality one of the following scenarios might happen:

  1. All parties agree and the functionality will be developed
  2. The relevant persons didn’t show up for the meeting and thus no agreement could be made which delayed the process
  3. The relevant persons couldn’t come to an agreement

And here is how you can manage those three scenarios.

  1. Grab a cup of coffee, sit down, and smile
  2. Arrange another meeting and make it abundantly clear who should attend the meeting and their responsibility
  3. If they couldn’t come to an agreement you have to escalate the issue to the steering group and they have to take a decision

My Lesson Learned

I have experienced all three scenarios in almost every project I have been involved in.

My big lesson here is about meeting organization.

In meetings where thing are to be discussed and decided upon I always do these four things:

  1. Make an crystal clear agenda
  2. Timebox each topic
  3. Assign responsible persons for each topic
  4. Invite the persons with the right authority

By doing these four thing I make sure everybody shows up and are prepared. If we can’t come to an agreement the person who has the final say are also in the meeting.

  1. Functions first, not processes

Women writing a process with empty boxes.

Women writing a process with empty boxes.

Yeah…

That’s not quite right.

Processes should come first, not functions.

Sometimes you can let the project spend a lot of time defining a functionality, get it developed and put into production only to realize that it doesn’t reflect the reality of how people work.

Why does this happen?

Because you focused on functionality before processes.

Just as fine any functionality is we really need to understand why and how we want to work before focusing on defining functionality.

My Lesson Learned

Whenever I hear a lot of confusion and discussion about a new functionality a small red flag raises inside my head.

Then I ask the question if the functionality has any connection to the work process, or if there are any work process defined at all.

It is much better to delay a functionality and wait until the process is ready than to rush into developing something that is not fully understood.

  1. That’s not what I asked for

Guy received what he didn't want.

Guy received something he didn’t want.

Describing and explaining things face to face is quite difficult.

Want to make it even harder?

Try to do it in writing or by a crappy phone line.

Add to that possible language difficulties and it’s a miracle that you could get anything done.

The dialog between the customer and development team is crucial in any project.

If that communication isn’t working, you will experience a lot of problems.

So how can you make the communication work?

By using these techniques:

  1. Get the supplier and customer together for face to face meetings
  2. Involve the actual programmers in the discussions
  3. Always ask the supplier to document their solution suggestions, not only confirm that they understood it verbally
  4. Don’t be afraid to book extra meeting to discuss the functionality

These four techniques will help you minimize the “That’s not what I asked for” into “That’s exactly what I wanted”.

  1. Was that my responsibility?

Don't point at me.

Don’t point at me.

When something needs to be done you must be absolutely clear who has the responsibility and own the task.

Are you familiar with that great feeling you experience after a productive meeting?

Everyone showed up, participated, decisions and plans were made.

But, at the next meeting nothing was done.

Wait, what?

I thought everyone understood what they should do.

Probably everyone understood the task but no one were officially assigned to it, so it didn’t get done.

This brings us down to that  roles and responsibilities in projects must be clearly defined, documented and communicated.

Communicated not only once, but as often as needed. There is nothing wrong with being overly clear about who is responsible for what.

My Lesson Learned

One lesson learned from this is to use a good system for task delegation.

I have often used JIRA for this. In that system you can assignee responsibility to a specific person which makes it 100% clear who has the current responsibility for the task.

But just make sure you don’t end up in a “JIRA assignee war” where people throw the responsibility back and forth at each other.

In JIRA you can also add a lot of other useful information around a task like component, affected version, watcher, assignee, reporter etc.

  1. Where is John?

Anyone know where John is?

Anyone know where John is?

Getting people to participate in meeting is not always an easy task.

The decline reasons that pop up in my email client are plentiful; they are busy, on vacation or simply doesn’t want to participate.

When we are a maximum of 3-4 persons it can easily be solved by rearrange the meeting time.

However, when you have already scheduled a day and time and invited 10-15 people rescheduling the meeting is not always possible.

So, how do you get maximum participation for those kind of meetings?

  1. Clear agenda and expectations from each participant
  2. Make them present something of their own in the meeting
  3. Don’t invite persons that doesn’t make point one or two
  4. If they decline, follow up with a phone call talk about their reasons for not coming and see if it can be solved
  5. Meet the meeting expectations and make something good out of the meeting so that the participants will be more inclined to participate in the future
  1. Decisions from meetings – let’s (not) ignore them!

Follow up decisions.

Follow up decisions.

If you do proper preparations you will increase your chances of having a great meeting.

But the work doesn’t stop there, you must put in at least equal amount of work after the meeting.

Your two main responsibilities are:

  1. Send out a meeting review
  2. Follow up on decisions made

Number two on that list is crucial.

Because if you don’t follow up on what was decided, people will start to feel that your meeting has no value, they will start to think they are a waste of time.

And eventually they won’t like to participate.

So, it is very important to follow up on what has been decided so make your meetings a true success.

  1. Listen to me!

Listen up!

Listen up!

How do you know what kind of functionality you should be delivering?

You ask the users! (Unless you are Steve Jobs)

But that was the easy question. The tough one is: How do you ask the users?

One obvious way is to send out a survey. But you should also consider interviewing your end users.

If fact, Ash Maurya spends one third of his book Running Lean telling us how and why interviews are the best method to get feedback.

Your game plan should look something like this:

  1. Identify users that have an interest in your project/software
  2. Conduct 30 minute interviews with them
  3. If possible, put them in charge of defining the functionality, explaining it to the supplier and also testing it

This will give your chosen users a great feeling of involvement and make them excellent promoters of the project.

  1. I have my own system

I make my own decisions.

I make my own decisions.

As a project manager you will be in charge of setting up the plan, framework and techniques used for your project.

That is an essential part of your job.

But from my experience you might run into people that have their own way of doing stuff, and they are not interested in changing that.

And that is OK, you should be flexible and leave some decision to the single project members to keep their locus of control high and thus also their motivation.

My Lesson Learned

One small example is JIRA vs Excel.

A member of one of my teams didn’t like JIRA and used her own system of tracking tasks in Excel.

We tried several times to get her into JIRA but our attempt didn’t succeed.

But in the end of the day, did it matter?

The answer is both yes and no.

Although she didn’t always have the latest status of the tasks from the development team, she stayed motivated and worked hard with her tasks by making the decision to use Excel instead of JIRA herself.

If we had to force her into JIRA she would have gotten demotivated and we would have had a bigger problem on our plate.

  1. What’s the status?

It's a dashboard, very useful.

It’s a dashboard, very useful.

There is usually a lot of people involved in a project.

And most of them are interested in getting the right information and status regarding your project.

From my experience these are the best way for informing others of the status:

  1. Set up a high level overview of the project on a big wall
  2. Use digital dashboard for a detailed status

The high level overview is meant to show everybody the road-map and status at the general level.

This will enable people to just swing by and have a look, this will also give you the opportunity to strike up a conversation with the them easily.

The digital dashboard is for creating a more detailed status of the progress. This is kept digital since the changes here happen more often so it would be a full time job to reflect all changes manually on a wall.

  1. Loading, loading, loading…

Just wait a bit more...

Just wait a little bit more…

People are impatient and people don’t like to wait.

There have been many studies published about for how long people wait until they get frustrated and leave a website/software.

So, you should really be focusing on building a high performing system. This should ideally have been defined in the project contract, with for example the acceptable average loading time for a user.

But in my experience the performance issue is largely ignored until it becomes a problem.

But then it is too late.

Your system will be the cause of frustration and will get a bad reputation of being slow and not very usable.

There are numerous of different ways of generating and measuring the performance of a system/software.

But whatever approach you choose make sure you make it an essential part of your project.

  1. We got hacked!

Be aware of hackers.

Be aware of hackers.

An often overlooked part of an IT project is the security.

99% of the times this isn’t a problem. But when it does become a problem, it becomes huge problem with severe consequences.

All it takes is a decent hacker with evil intent to break your system.

So, you should really involve security testing as an integrated part of your project. They way it should work is two-fold.

For one you need to educate the developers in how writing secure code. And on the other end you need to arrange proper penetration testing of the system.

And don’t forget to also test social engineering techniques.

  1. It is ready for test…

Time to test!

Time to test!

When a developer finished developing a task you will often get a short message saying it is ready for testing.

But even though the tasks has been clearly defined and what was done is easily understood by the developer the person who are to test it needs more information of what has been done.

Too often I hear that the person who is about to test doesn’t know how the supplier solved the task and how to test it.

This boils down to bad communication.

The solution?

Arrange a meeting where the developers can present and demo the new functionality. And only after that the customer can test and verify it on her own.

Letting the developers demo the functionality themselves also adds extra motivation for them to do some testing on their own beforehand. It also adds an opportunity to identify issues together at the demo meeting.

  1. Ain’t nobody got time for that

A lady with no time.

A lady with no time.

Usually people involved in a project are not engaged full time.

They have a lot of other responsibilities and work to do.

So, when you ask them to do something project related a common reply is that they don’t have the time.

But, you should not be satisfied with that answer. As Michael Bungay Stanier recommends in his book The Coaching Habit you should not be satisfied with the first answer but dig deeper.

If they answer they don’t have time, ask if there is anything else stopping them, and when they answer ask them again.

Keep asking until you get the real reason.

Because not having the time is not a valid answer. It is all about prioritizing, and the real reason you want is why your project is not prioritized.

My Lesson Learned

I had some trouble getting people to take the time and test in one of my project. What I did to solve it was to book in a meeting with them where we sat down and tested together.

This created a time block in the calendar dedicated for testing. If it weren’t for my involved they probably wouldn’t have taken the time for it.

And in the end they started doing it on their own as well.

This method can also be improved to include more people and do a full day activity fully decided to whatever task that need to be completed.

  1. People go outside agenda during meetings

Bad meeting.

Bad meeting.

When you have a meeting with other people you will have to deal with a managing them to stay focused on the agenda.

I think we have all been in meetings where the majority of the time is spent listening to some rant, or what somebody did last weekend.

This can be important and interesting – but to talk outside the agenda is often the root for a lot of frustration and causes a bad meeting culture.

To avoid this you need to have a clear purpose and agenda for the meeting. And you must not be afraid to cut people off when they freestyle into something outside of the agenda.

But if the topic can be relevant in another setting you can write it down and follow it up.

However, you should make room in your project for people to speak freely, and also make sure everybody speaks pretty much the same.

This creates a psychological safety in your team which is one of the most crucial aspects of creating a high performing team.

But there is a time and place for everything, use special meetings where it is allowed to “freestyle”.

  1. Stakeholders are not involved

Project Stakeholders

Project Stakeholders

In the beginning of a project, one of your tasks is to identify the stakeholders.

Unfortunately, sometimes you identify key stakeholders whom does not participate as much as you would like in the project.

This can cause problems in the long run since they might have a lot of authority, but you won’t get their input until the very end of the project.

To solve this make a small plan on how and when to involve these key stakeholder and serve them the information they need.

This will naturally be a part of your communication strategy. But make sure it is followed and that it works like intended.

What’s your lessons learned?

What’s your take on these lessons learned? 

And what are your own lessons learned?

Let us know in the comments below.