Karl Wiegers shares his lessons on requirements, project management, design, quality and more. Karl’s advice can make you significantly better at what you do.

Show Notes

Karl Wiegers started programming in 1970 and has collected 60 lessons he has learned in several areas of software development including requirements, design, project management, culture, teamwork, quality, and process improvement. Each of these lessons bring insights that can help you to and your organization to become significantly better at creating high quality, valuable solutions to your customers.

The Need to Iterate

Almost everything we do takes more than a single shot and design is a good example. The first lesson in the design category of Karl’s book is “design demands iteration”.  There’s always more than one design solution for a software problem and seldom a single best solution.

The first design approach you come up with is unlikely to be the best option.  A good rule of thumb is that you’re not done with design until you’ve created at least three designs, discard them, and take the best ideas from those three and build something better.

The same holds true for requirements.  It will take a few iterations to get it right.  These are cyclical things that you have to plan in your project management approach.  You’re going to have to build in some reviews, get some feedback, prototype, and do some modeling to make sure we’re on the right track.

Icebergs are always larger than they first appear; that means that there’s going to be growth in the project. There’s going to be new information and new ideas that come along.  You have to build in that growth and include contingency buffers into your plans.  The bigger the project, the more unknowns and ambiguity and the more likely it is to change.

Understanding Stakeholders and Customers

Usage-centric development (as opposed to user-centric) is more likely to satisfy customer needs than product or feature-centered development.   We shouldn’t care about features as much as you care about knowing what people need to do with the product.  That’s the difference between the usage-centric approach and the product-centric approach.

That begins by understanding your stakeholders.  Stakeholders are individuals, groups, or even systems who can shape or influence the direction of a project or who are affected by the project.  To be successful, you need to identify your various user classes and identify who’s going to be the literal voice of the customer. Keep in mind that the customer isn’t always right, but they always have a point.  Many times, the customer may ask for a solution, which may or may not be the right thing.  To provide valuable solutions, we need to understand the underlying problem.  If the solution they propose is the answer, what is the question?

Listen to the full episode for more lessons and advice on stakeholders, quality, applying what you’ve learned, and more.


Pick two areas you want to get better at and vow to spend some of your time on the project learning about those areas. Look for opportunities to apply that new learning on your project and perform in those areas better than you would have before your commitment to learn and develop your skill in that focus area.

Links Mentioned in this Episode

Karl Wiegers

Karl Wiegers

Karl Wiegers is an independent consultant, author, speaker, and thought leader in the project community. His books on software requirements are considered required reading for Business Analysts and Project Managers. As a consultant and trainer, Karl has worked with more than 100 companies and government organizations of all types, helping them improve the effectiveness and efficiency of their software development activities.

Thank you for listening to the program

To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes.

Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.