You can tell the maturity of a market by the consumer patterns.  If you know the life cycle stages of a market you can better anticipate what level of "needs" your product needs to match to be successful.  (I always think of needs in stages like Maslow's hierarchy.)

The Four Stages of Market Maturity

• Stage 1. Survival
• Stage 2. Quality
• Stage 3. Convenience
• Stage 4. Customization.

From Survival to Customization
In the Autumn Special Edition of "strategy+business" magazine,  Alonso Martinez and Ronald Haddock describe how a country evolves from developing nation to industrialized nation:

"As a country evolves from developing nation to indusrialized nation, the population's basic needs pass through four distinct stages.  In developing countries, most of hte population is preocupied with basic survival - obtaining adequate food, shelter, and clothing. (Much of sub-Saharan Africa is in the stage right now.)  As a middle class emerges, people seek greater quality in their food, housing, and clothing (This is currently happening, for example, in much of China and India.)  Once a transitioning market's population can afford relatively high quality, they begin to seek convenience; they buy time-saving appliances and processed foods, and they may move closer to work.  (This stage is emerging today in Eastern Europ and Latin America.)  Finally, as the market graduates into the realm of developed nations, the population wants customization; with needs for survival, quality, and convenience now met, people will spend a premium (as many do in North America, Japan, and western Europe) to satisfy individual tastes and desires."

Key Take Aways
I think to successfully anticipate global market needs, you need to understand where in the stack, various consumers are.   I've noticed a lot more attention on customization, particularly in social software and personal devices.

I read an interesting article on behavioral economics by Harry Quarls, Thomas Pernsteine, and Kasturi Rangan, in "strategy+business" magazine.  According to the authors, behavioral finance supports a counter-intuitive strategy of loving your market "dogs" (underperformers) over your stars.  They pose a few questions up front: 

• What if conventional wisdom is wrong?
• What if corporations would be better off shortchanging their stars and nurturing their dogs?
• What different decisions would managers make then?

Conventional Approach is Stars Over Dogs
Quarls, Pernsteine, and Rangan write:

"In the course of maximizing shareholder value, senior executives routinely face decisions about which of their companies' businesses should be nurtured, which should be starved, and which should be sold. The typical strategy is to invest more heavily in the 'stars' that are earning superior returns on capital, while starting or selling the underperforming 'dogs' This is the conventional approach in corporate finance and has become so ingrained in corporate finance and has become so ingrained in management practice that it is almost impossible to question it."

Way to Thrive is Love Your Dogs
Quarls, Pernsteine, and Rangan write:

"There is, in fact, reason to believe that the conventional wisdom is wrong. Corporate managers often rely on accounting metrics to make business decisions. However, these metrics are based on past performance; the market is interested only in the future. And past performance is generally a poor predictor of the future. Thus, when performance is assessed over time, greater shareholder value can be created by improving the operations of the company's worst-performing business. The way to thrive is to love your dogs.

Just as some fund managers earn superior returns by identifying and buying undervalued 'market dogs' - better known as value stocks - corporate leadership can learn to identify 'value assets,' hold and nurture them, and produce superior performance. This in turn will ultimately lead to an increase in shareholder value."

3 Messages for Corporate Leaders
Quarls, Pernsteine, and Rangan have three messages for corporate leaders:

• Fixing your dogs can yield unexpected levels of shareholder value.
• Improving operations is an important management lever for adding shareholder value.
• Buying and fixing someone else's dogs will produce more shareholder value than buying stars.

Key Take Aways
I think there's several interesting points.

• Intrinsic value vs. market value. The intrinsic value of a bottle of water might not be much, but what's the market value out in the middle of the desert? This is why markets boom or burst. What's the intrinsic value vs. market value of your dogs?
• Innovation cycle. One type of mistake with R&D projects is over-investing in the beginning, then under-funding them later when it counts. The market isn't always ready, and buy-in takes time. What if your R&D dogs are starving before they become stars?
• Growth opportunity. Where's the most growth? Squeezing more out of your star, or helping one of your dogs to the top?   It's always tempting to squeeze some more golden eggs from the goose. 
• What's the market demand. If the market is interested in the future? Is the star the best fit, or one of your dogs?

Personal Development
To sanity check ideas, I like to test them against personal development concepts.  It can help quickly put things in perspective.  For example, should you invest more in your star skills or improve your dogs? Conventional wisdom to go from good to great is work on your star skills. However, a liability can hold you back (think in terms of Kano -- a dissatisfier can really undermine all your satisfiers.) But, what if you have a few skills that are diamonds in the rough, or what if there's a good chance of downstream market demand?

Project Management
I manage a portfolio of results, so I also like to test ideas against project management practices.  For me, I tend to use a few key factors around deciding where to spend energy and time:

• Intrinsic value.  Is a dog's intrinsic value hidden in the shadow of a star's limelight? Is there a dog with latent value, suffering from a lack of customer demand generation?
• Capabilities / Liabilities.   Is a dog capping the impact of a star?  Is there a dog that would reduce operational liabilities or improve operational capabilities?
• Impact.  Sometimes a dog is a long shot.  It's also a potential game changer. 
• Trends.  I try to bet on trends over fads.  For example, I think in our software industry, there's key trends around social software, personalization and specialization.  It's a reflection of market maturity and customer demand.  In other words, narrowing the focus is one way to win in a market niche.  For example, if My Space is an optimized blog experience for a certain audience, what would an optimized blog experience be for a developer audience?  Would it optimize around sharing code snippets and patterns?   Would there be virtualized experiences and integration with Visual Studio?  Personally, I'd like to see federated "guidance spaces" for personal prescriptive guidance blogs. 
• Windows of opportunity.   Is a star past its prime?  Is there a new dog in town?  Can a new dog reinvent or help rehydrate a star? 

From a dog and star standpoint, I like to count on my stars, but I experiment with a lot of dogs, since the rate of failure is pretty high, but it's the future of the dogs that help me stay adaptable over getting overly adapted.  Put it another way, what got me here today, won't get me there tomorrow.

If you're looking for yet another way to help you prioritize your backlog or to help you shape your product's design, consider the Kano model. One concept in the Kano model is satisfiers and dissatisfiers.  You can think of satisfiers as features you might ask for.  You can think of a dissatisfier as an unmet need.  It's something you wouldn't necessarily ask for (latent need.)  You just expect it. It's absence is a dissatisfier.

Examples
Here's a few examples:

• As a colleague put it, if you buy a new car, you might ask about features of the engine or luxuries, but you just expect it to have a speedometer.  If there's no speedometer, you'll be dissatisfied.
• Spelling more words correctly won't make your article great.  At the same time, consider the negative impact of spelling a bunch of words incorrectly (dissatisfiers)

Key Points
Here's the keys:

• At some point, adding more satisfiers doesn't necessarily increase satisfaction.
• Addressing a dissatisfier doesn't necessarily increase your satisfaction.
• Not addressing a dissatisfier can exponentially decrease satisfaction.

Applied Use

• You can imagine the impact on a product design.  You add a bunch of features (satisfiers), but ignore some dissatisfiers (performance, security, reliability, usability.)  That's a common pattern in failed product designs.
• You can think in terms of your job.  Do you deliver satisfiers or do you reduce dissatisfiers?  Some "dissatisfier"jobs are undervalued or unappreciated until disaster strikes, then their exponential value becomes obvious.
• You can think in terms of your life.  Do you add satisfiers or do you decrease dissatisfiers?  could reducing a few dissatisfiers exponentially improve your life?

 My Relates Posts

• Personas at patterns and practices
• Actors, Personas, and Roles
• Task-Analysis Grid for Communicating Product Design
• Scenario and Features Matrix
• Scenarios in Practice
• Scenario Evaluations for Product Design and Feedback
  

Routines help build efficiency and effectiveness.  Consistent action over time is the key to real results.  If you add continuous improvement or Kaizen to the picture, you have an unbeatable recipe for success.  The following are some of my rituals for results: 

• Put in your hours.  I heard that Hemingway wrote for two hours a day.  The first hour he edited the day before.  The next hour, he wrote new.  My marathon runner friend says the key for her is putting in her hours.   
• Schedule It.  If you schedule it, it happens. ("One of these days is none of these days.”)
• Carve out time for what's important.  You don't have time, you make time.  "Work expands so as to fill the time available for its completion." - Parkinson's law.  "Things which matter most, should never be at the mercy of things which matter least." - Goethe.
• Model the best.  Success leaves clues.  Using reference examples can help you shave off tons of wasted time.  Who can you learn from that will take your game to the next level?
• Expand your toolset.  When you only have a hammer, everything's a nail.  Adding new tools to your toolbelt can exponentially improve your results.
• Build a library of reference examples.   Collect working examples to draw from.
• Build feedback loops.  I think feedback loops help us improve and keep us going.  For me, I use a sounding board of people I trust. 
• Have a compelling "why."  A compelling "why" is what will give you the energy and get you back on your horse, when you get knocked down.
• Have a compelling "what."  Your "what" should be a great manifestation of your "why."  Use it to guide your course.  This is your vision.
• Check your ladder.  Is it up against the right wall?  Nothing's worse than climbing a ladder to find your destination was wrong.
• Work backwards from the end in mind.   Working backwards from where you want to be can help make you more resourceful.  Look to working examples and reverse-engineer.
• Stay flexible in your approach.  Be flexible in the "how."  If you have a compelling "what" and "why," you'll find the strategies.  If something's not working, change your approach.  Sanity check by asking yourself "is it effective?"  See The Better Adapted You Are, the Less Adaptable You Tend to Be. 
• Think in terms of a portfolio of results.   This means both producing results in different categories as well as having some results you count on and some that are risks.  Diversify your results over having all your eggs in one basket.
• Balance your buckets.  Balance your results across your meaningful buckets.  For me, I use a life frame (mind, body, emotion, career, financial, relationships)  Within my career bucket, I make time for results, thinking, administration, improvement and relationships.
• Establish a rhythm of results.  Don't let the tail wag the dog.  Factor your creation cycles from your release cycles.  Your release rate should match absorption rate and demand.  Your production rate doesn't need to be tightly bound to your release.  For instance, you could write your eight blogs posts on Sunday, then trickle out over the week. See Drum-Buffer-Rope.
• Deliver incremental value.  Chunk it down.  Focus on value-delivered over backlog burndown.  It can be easy to be productive, but ineffective.  Focusing on delivering value, keeps you asking the right questions and making the right calls on priorities.  Remember that backlogs tend to suffer from rot over time.  If you focus on value-delivered, you'll miss less windows of opportunity, or at least you're considering those windows when you prioritize.  The other secret here is that focusing on value can be more energizing than tackling an overwhelming backlog, even if all you really changed is perspective ;)
• Know the sum is better than the parts.  Consistent action over time produces real results.  Think about how much you've accomplished over the long run, just by showing up at work every day and doing your job.  See How To Overcome Resistance.
• Improve your network.  Who you spend time with probably has the largest impact on getting results, personal growth, your quality of life ... etc.  Tip - build a mind map of your personal and professional networks and see where you need to tune, prune or plant.
• Play to your strengths.  Improving your strengths can help you achieve more than improving your weaknesses.  The exception is liabilities.  Reduce the liabilities that hold you back.
• Reduce your context switching.  Context switching is one of the worst productivity killers. If you're spending more time switching than doing, it's a problem.  Consider how you apply the following software patterns and practices: batching, remote facade, implicit lock, lazy load, coarse-grained lock, proxy, RI and FI, buffers, and Drum-Buffer-Rope.
• Manage energy for results.  Manage energy, not time for results.  When you're "in the zone," you get results.  How well do you get things done when you're emotionally or mentally drained?  See Manage Energy, Not Time and The Secret of Time Management.
• Use focus as your weapon for results.  Focus is your friend.  A batched and focused effort can produce amazing results.  Few problems withstand sustained thinking or effort. 30 Day Improvement Sprints, Why 30 Day Improvement Sprints, Making 30 Day Improvement Sprints.
• Reduce friction.  Create streamlined execution paths.  create a fast path for stuff you need to do frequently.  There's probably a few scenarios where you have more friction in your process than you'd like.  I use 30 Day Improvement Sprints for my perpetual friction points.
• Use checklists.  I'm a fan of using checklists.  If the air force can use them to avoid task saturation and improve effectiveness, so can I.  See Execution Checklists and How To Avoid Task Saturation.
• Build a system of profound knowledge.   See The Deming System of Profound Knowledge and Deming's System of Profound Knowledge  This is about thinking of the system as a whole, knowing the impact of changes in the system, focusing on knowledge management, and taking into consideration the people-side of things.  Remember that just because you might not be in a learning organization, doesn't mean that you can't set an example.
• Do more, think less.  I'm not advocating thoughtless actions.  I'm countering actionless thoughts.   Thoughtful actions produce results.  If you're already acting on your ideas great, otherwise, action is the best oil for rusty results.

Try the ones you like.  Experiment with the ones you don't.  You might get surprised.  As Tony would put it, "If you do what you've always done, you'll get what you've always gotten". Adopt a growth mind-set over a fixed mind-set.   I'd be interested in hearing success stories or your favorite rituals for results -- what techniques have personally served you well?

Do you have a favorite set of forcing functions?  In patterns & practices, one of our forcing functions is building a slide deck.  Building a deck is a forcing function because it forces us to distill the points, close down on issues, identify what we know, don't know and need to know next in a fairly constrained way.  It helps to balance our elaboration on certain issues.

I like to use blog posts as a forcing function.  There's plenty of topics I could write books on, but I like using a post as a forcing function to chunk something down into a nugget of insight, or a collection of nuggets of insight.

Kaizen is a Japanese term for continuous improvement.  A little Kaizen goes a long way over time.  From a personal development standoint, it's key for overcoming resistance.

Book building is art and science. I've built a few books over the years at patterns & practices. In this post, I'll share a behind the scenes look at what it takes to do so. I'll save the project management piece for another day, and focus on the core of book building. 

Book Examples
Before we get into the details, here's a quick look at my past books:

• Team Development with Visual Studio Team Foundation Server (Amazon, HTML, PDF)
• Performance Testing Guidance for Web Applications (Amazon, HTML, PDF)
• patterns & practices Security Engineering Explained (HTML, PDF)
• Improving .NET Application Performance and Scalability (Amazon, HTML, PDF)
• Improving Web Application Security: Threats and Countermeasures (Amazon, HTML, PDF)
• Building Secure ASP.NET Applications (Amazon, HTML, PDF)

If you're familiar with the books, particularly Improving Web Application Security and Improving .NET Application Performance and Scalability, you'll know that the books aren't like typical books. They're optimized to be executed rather than read. The expectation is you'll use them to improve your effectiveness on the job. That's why you can get the books in the bookstore, online or in Visual Studio ... in print, PDF or HTML.

Competitive Assessments
The books are targeted at real-world problems and real-world solutions.   They've been used for competitive assessments:

• Security Innovation Security Engineering Study
• Openhack 4 (EWeek Labs): Web Application Security
• @Stake Security Study: .NET 1.1 vs. WebSphere 5.0

Book Approach
At a high-level, you can think of the approach in five main workstreams:

1. Researching and analysis.
2. Designing.
3. Building,
4. Testing.
5. Releasing.

It's a "test-driven" approach, meaning we start with tests (questions and tasks) that our prescriptive guidance needs to pass. The bulk of the work is building "nuggets" that can be used standalone.  We then assemble an end-to-end guide.   Throughout the process we verify with test cases, lab repros, internal and external reviews, both with subject matter experts and every day users.

Researching and Analysis
This workstream is about getting clarity on the problem space.  It includes:

• Identify the Key Resources in the Domain.  This is about finding all the relevant blogs, sites, articles, code, slides ... etc. for a given domain or problem area.  Here's an example of our Visual Studio Team System Resource List. 
• Identify the Key People in the Domain.   This includes enumerating internal folks (product support, field, product teams, experts) as well as external folks (partners, MVPs, customers, experts, ... etc.)
• Identify the Key Categories in the Domain.  Knowing the terms in the domain, speeds up our research efforts.  For example, if we know the names of the features for a product, we can quickly explore the product docs.  If we know how the community is tagging the information, we can quickly parse the broader "Web community KB."   Reviewing key blogosphere is a fast way to figure out the folksonomy that people use.  This helps us build information models for the space.
• Identify the Key Questions, Tasks, and Scenarios.   This is a process of making tickler lists of the questions that users ask, the tasks they perform and the key scenarios.
• Identify Key Contributors.   This includes finding folks that want to participate and actually create content.  A lot of folks raise their hands, but only a few deliver.  That's the nature of the beast.
• Identify Key Reviewers.   Finding reviewers is pretty easy since lots of folks want to steer.  The trick is finding the folks that inject insights and dramatically raise the quality of the guidance.  We cherish our key reviewers.
• Identify Key Reference Examples.  This is about gathering all the working examples we know of from support, field, and customers.  I like to be able to point to working instances of the guidance in practice.  I also like to reverse engineer success (success leaves clues.)
• Build data points.  If you're into information, these would rock your world.  These are dense collections of insights that we share among the team.  Sometimes we use a Wiki, but we always use Word docs to capture and share them, since they get are very dense and we track the sources of the information.

For more information on researching, see my related posts: Analyzing a Problem Space and How To Research Efficiently.

Designing
This workstream is an iterative process of spiraling down on solutions.  It includes:

• Create a scenario frame.  This is where we frame out the guidance.  It includes organizing scenarios into key categories and sub-categories.  This is where the folksonomy and information models helps.  Here's examples of our Visual Studio Scenario Frames.
• Review the scenario frame.   This is painful but rewarding.  We review the scenario frames with customers and experts, internally and externally.  It's a spiral down process.
• Identify the priorities.   Once we have scenario frames and we've spent the time reviewing, we're at a great vantage point to separate the forest from the trees.  One technique we use to prioritize is we ask product team members to think of the top 10 issues they'd like to make go away from their inbox ;)
• Identify candidate nugget types and titles.   This is where we figure out whether something should be a "How To" set of steps or an "Explained" articles, such as an explanation of how something works or it's intended usage patterns.  We hammer on the titles so that they both represent compelling information, they set the right expectations, and they are more findable on the Web.
• Identify the objectives for each nugget.  We identify the key "tests for success" in each nugget, by listing the specific tasks, questions or objectives you'll accomplish by using that particular nugget.  For an example, see the "Objectives" section in How To Protect from Injection Attacks in ASP.NET.
• Prototype the Table of Contents (TOC.)  I do this on the whiteboard and paint the broad strokes first.  I factor the guide into two main parts: a fast path through the key strategies and concepts, and an actionable reference of nuggets (principles, patterns and practices.)  I also come up with a story I can tell in the hall.  For example, the story behind Improving Web Application Security was "how to build a hack proof app."  That set the stage and kept things on track when things got complex (as they always do.)
• Create conceptual frameworks.   This involves figuring out the most effective ways to look at and tackle the problem space.  For examples, see Performance Fast Track and Security Fast Track.

For more information, see my related posts: Guidance 2.0, Scenarios in Practice, Scenario Frames for Guidance, and Driver's Guide vs. Owner's Manual.

Building
This workstream is where we do the bulk of our solution engineering.  It includes:

• Prototype nuggets.  This is where we frame out and create skeletal examples of nuggets.  We incrementally render the final nugget by adding information and details as we learn, build, and test.
• Create problem repros.  Reproducing problems helps to both understand the problem space as well as make it easier to share the problems and get more eyes on them.  We also need to be able to test the solutions against the problems.  We typically capture problem repros in notepad.
• Create solution repros.   This is where we create the leanest, stripped down example of solving the problem.  We capture these as steps in notepad, including copy+pastable code or configuration steps as needed.  Each person on the team should be able to quickly run through the solution repro.  This helps us find the sticking spots and reduce the friction.
• Create key figures.   This is a painful process.  The goal is find the fastest way to convey the information visually.   I think my favorite all time examples are our "cartoons" for showing our security scenarios and solutions.
• Write nuggets.   This involves fleshing out the details.   I try to keep the text as tight as possible throughout the process.  It's more work to make it dense, but it pays off where we spend the time.
• Write chapters.  This is similar to writing the nuggets but from a zoom level this is where it's about showing the forest.
• Modify the TOC.  This is a continuous process.  As we learn more about the space, it gets easier to organize the chapters and nuggets into parts and a story that we can stand behind.
• Refactor nuggets and chapters.   For an example TOC, see the Landing Page for Improving Web Application Security.

Testing
This workstream is about verifying the solutions from both a technical and user experience perspective.  It includes:

• Test solutions in the lab.  Since the bulk of our books are executable, it's fairly straightforward to test the solutions to make sure they work in the lab.  Scenario and scoping is important, so this is where our scenario frames and objectives for each nugget really help.
• Test solutions in the field.  This is where we try to find customers that share the problems we've solved and put our solutions into practice.   Usually, this involves leveraging our field or product support that acts as a proxy for the customer.  We also have a few customers running alongside us that can help test in their scenarios.
• Dog Fooding.  One rule I have on our team is eating our own dog food so we have first hand experience with the usability of the guidance and can directly use it to solve problems.  See Eating One's Own Dog Food on Wikipedia.
• Review solutions.   This includes reviews from internal and external stakeholders.  We do this incrementally.  First our immediate team has to approve, next our immediate key contributors and reviewers (the ones that have more bandwidth and commitment) and then more broadly (such as on CodePlex.)  For an example of the sets of reviewers, see the Landing Page for Improving .NET Application Performance and Scalability.
• Improve solutions.  Rather than just focus on finding issues or proving that something technically works, it's about raising the bar in terms of user experience, or finding a more effective technique or solution.  We use Timeboxing to help scope. See How To Use Time Boxing for Getting Results.

For more information, see my related post: Test-Driven Guidance.

Release
This workstream is about making the guidance customer available.  It's incremental, iterative and we stabilize over time.  it includes:

• Create an online community KB.  This is where we create an online site to share the nuggets.  For an example, see our Visual Studio Team System Online Community KB on CodePlex.  By sharing the nuggets here, we can test and vet before baking into more durable form factors such as the PDF and print versions.
• Create a PDF.   We do this once we've stabilized enough that the PDF is a good example, of what the final book will be.  While details may change, the overall frame is durable and we use the PDF as a simple way to share the book before we're baked.  For an example PDF, see patterns & practices Team Development with Visual Studio Team Foundation Server.
• Create the book.   This includes creating a fit and finish PDF, as well as creating print-quality graphics, and coordinating with our MS Press team to create the final print versions of the book, as well as getting the book on the shelf.
• Port to MSDN.   We port the guidance to a MSDN so that we get better reach and because customers expect it there.  In the ideal scenario, we host the PDF and HTML, as well as have a print version.

Keep in mind that it's a stabilization process over time of various form factors and channels.  We do our agile guidance on CodePlex, then stabilize and port to MSDN and a book when we're baked.  For more information, see my related post CodePlex, GE and MSDN.

Key Concepts
I walked through the process first so that you have a good idea of the end-to-end approach.  Here I'll highlight some of the key concepts that underlie my approach:

• Solution Engineering.  This captures the heart of what we do.  Rather than "writing a book", we're really engineering solutions for problems.  That's why the team includes architects, testers, developers ... etc.
• Question-Driven.  I'm a fan of using questions to prioritize, drive the scope, and figure out when we're done.  I know we're done when we've addressed enough of the right questions.
• Principles, Patterns, and Practices.  The bulk of the book is a collection of principle-based recommendations.  Although we don't always formally write up patterns or name the patterns, each book contains pattern-based solutions.
• Life Cycle Approach.  I find using a life cycle makes the solution stronger.  If I just give you technical guidance, that only helps you so far.  If I give you a system for results, it changes the game.
• Test-Driven.    I'm a fan of using explicit test cases for content.  See Test-Driven Guidance.
• Conceptual Frameworks.   This is the backbone of the guides.  This is where innovation happens the most.  These are mental models, lenses and perspectives, and systems for results.  For an example, see Fast Track - A Guide for Getting Started and Applying the Guidance.
• Scenario-Based Approach.  You can't do a design review in a vacuum.  We use scenarios to evaluate against.
• Scenario Frames.  Scenario Frames are organized sets of usage scenarios.   We use these to frame out the problem space.   See Scenario Frames for Guidance. 
• Executable Content.   Use the content to execute your tasks.
• Action vs. Reference.   One key to building executable content is factoring reference information from action.
• Guidance Types.  Another key to building executable content, is using specific guidance types.  For "reference" information, we use "Explained" nuggets.  For "action" information, we use "How Tos", "Checklists" ... etc.   Our guidance nugget types include: App Scenarios, At a Glance, Checklist Items, Code Examples, Explained, Guidelines, How Tos, Inspection Questions, Patterns, Practices, Principles, Roadmaps, Techniques, and Test Cases.  You can browse these collections using patterns & practices Guidance Explorer.
• Context-Precision.    This is a term I coined to get more specific about the scenario.  This improves both the modularity of our nuggets as well as the usability.  Rather than a single nugget spread over many contexts, we factor and use precision.  This avoid a spaghetti problem and helps reusability and maintainability.  See Context-Precision.
• Holistic Over Piecemeal.   The guides are meant to get you up and running.  The example I use is teaching you to drive.  I show you how to forward, reverse, steer, brake, shift to get you going and then drill into shifting or braking as needed, rather than show you how to go forward today, then how to reverse another day, and some day how to steer.  This means compressing and distilling knowledge that's been spread out over time and space.  
• User Effectiveness Over User Sat.  To do my job well, I focus on customer effectiveness over customer satisfaction.  Ideally, it's both, but there's a lot of FUD in our industry and satisfaction is very subjective.  I find it more reliable to focus on measuring and testing customer effectiveness.
• Criteria for Effectiveness.  Part of what makes this successful is having criteria for the guidance which includes: Compliance with proven practice, complexity, quality, user competence and time to implement.
• Incremental Adoption.  Each guide is designed to be incrementally adopted.  While the sum is better than the parts, I can't ignore the reality that incremental adoption is more likely than monolithic adoption.  That's why the guides can be read end-to-end, or just grab the parts you need.
• What To Do, Why, and How.  While this pattern directly applies to writing prescriptive guidelines, it really exemplifies the overall guide.  Rather than lose you in endless enumerations of options, you should be able to quickly figure out what to do, why, and how throughout the guide.
• Entry Points.    How does a user find the specific guidance they're looking for?  I tend to focus on "question-based" entry points and "task-based" entry points.  You're either asking a question or trying to figure out how to do something.  For an example of question-based entry points, see VSTS Source Control Questions and Answers.  For an example of task-based entry points, see ASP.NET 2.0 Security Practices at a Glance.
• Team Guidance.   Few problems can withstand sustained thinking.  No problem can withstand sustained collective thinking.  To get an idea of the team-based approach, see the list of contributors and reviewers at the bottom of the Landing Page for Improving .NET Application Performance and Scalability.
• Customer-Connected Engineering.   Simply put, this means involving customers throughout the process.  How would we know we have the right problems or the right solutions without involving the people it's for?

Feedback
How do you build books? If you have thoughts, questions or feedback on my book building approach, feel free to share them here or drop me a mail.  While this approach has been proven effective over time, there's always room for improvement.  I'd like to hear what works for you.  If you're a fellow book builder, please share your approach.

My Related Posts

• CodePlex, GE, and MSDN
• Guidance 2.0
• From Guide to Guidance Modules
• Test-Driven Guidance
• Writing Prescriptive Guidelines

One of the questions I get is how we build and publish our guides and what's the relationship of CodePlex, GE and MSDN.  At a high-level, we build reusable guidance nuggets for customer questions and tasks.  We then build a larger guide to bring the nuggets together into a story. Together, this gives us both a knowledge base of nuggets and a series of guides.  We can incrementally deliver value, refactor as appropriate, and respond to changing needs.

Bird's-Eye View of Agile Guidance Engineering
You can think of our approach as progressive rendering of solutions (incrementally sharing and stabilizing.)

From CodePlex to MSDN
As we build guidance modules, we publish them to GE and CodePlex.  GE lets you, the user, build more relevant views or tailor the nuggets to your own needs.  CodePlex gives us a place to experiment with views and get direct user feedback, while we vet the guidance. 

Once we're stable, we do a focused, batch effort to port to MSDN.  MSDN gives us a bunch more channels and hooks including integration in Visual Studio / Visual Studio Team System.

There's much more to the story, so if there's interest, I'll share a behind the scenes look at how we build books.

My Related Posts

• Test-Driven Guidance
• From Guides to Guidance Modules
• How To Write Prescriptive Guidance Modules

What's one path the SDL (Security Development Life Cycle) can take to amplify impact?  From my perspective, I think the key is specialization for app types and verticals.  I base this on lessons learned from  shaping prescriptive guidance over the years, the market trend for specialization, and what I learned doing competitive assessments. I also know the enormous difference that getting specific can make (for example, our original patterns & practices threat modeling was one-size fits all -- now we shape it based on app type.  This lets us integrate more precise "building codes," patterns, and recommendations.)

Conceptual Framework / Mental Model
Here's a strawman I put together of a conceptual model to paint the possibilities.

App Types
Imagine app-type specific prescriptive guidance, services, tooling, process  ...

• SDL for Web Applications
• SDL for Mobile
• SDL for Web Services
• SDL for SDL for Smart Clients
  … etc.

Verticals
Imagine SDL for verticals ...

• SDL for Manufacturing
• SDL for Financial
• SDL for Retail
  … etc.

Key Concepts

• SDL for App Types means specific “building codes” (ASP.NET security guidelines, ADO.NET security guidelines … etc.)
• SDL for Verticals means industry specific guidance for security requirements (HIPPA, … etc.)
• SDL for Vertical and App Types can be turned into “Factories”
• SDL for Verticals and App Types can be turned into “MSF Templates”
• SDL for Verticals and App Types means “right-sized” services.

Key Assets
My take on what the various parties bring to the table ...

• patterns & practices.  Expert techniques, guidelines, checklists, patterns, “building codes”, how tos, Factories, Guidance Explorer, Vertical Solutions, Customer Verification, Influencers, MSDN Channel, VSTS channels/hooks.
• ACE.  Execution / Services Delivery excellence, libraries of threats, attacks, vulnerabilities, countermeasures, Enterprise Threat Modeling Tool.
• Visual Studio Team System.  Factories, MSF Templates, Code Analysis Rule Sets, Code Analysis Tools, integration of people/process/tools.
• SDL Team(s).  Process Model, Product Recommendations, Security Engineering excellence

While it requires a bit of coordination and focus in key areas, I think it's both technically feasible and would deliver a ton of customer value.  The sum is better than the parts.  Thoughts?

Threat Modeling is a way to identify potential security issues to help you shape your application's security design.  If you need to create a threat model, and you aren't sure how, here's some links to get you started.  (Note that our patterns & practices threat modeling approach is adaptable for agile scenarios.  In fact, our dominant set of customers we tested our approach with were using agile methodologies.  I'll cover doing agile security another day. )

Getting Started

• At a Glance: Threat Modeling Web Applications
• How To: Create a Threat Model for a Web Application at Design Time
• Walkthrough: Creating a Threat Model for a Web Application
• Template: Web Application Threat Model
• Template Sample: Web Application Threat Model
• Cheat Sheet: Web Application Security Frame

Key Links

• Threat Modeling Web Applications (Landing Page)
• Alex walks through our Threat Modeling approach
• Security Engineering Explained

My Related Posts

• How Do I Explain Threat Modeling to Customers
• What Makes a Good Threat Model
• Threat Modeling Terms and How To Use Them
• High ROI Security Activities
• Security Approaches That Don't Work
• Security Engineering Explained
• Video: Proven Practices for Security Engineering

This is an oldie but a goodie.  Alex (from our original team) walks through our patterns & practices Security Engineering Approach.   I knew the video exists, but I had a hard time finding it again so I'm posting the link here.

Video

• MSDN Architecture Webcast: Proven Practices for Security Engineering (Level 300) 

Key Changes
A few things have changed since our original video:

• We changed from reviews to inspections (Security Design Inspection, Security Code Inspection, and Security Deployment Inspection)  In our approach, we *inspect* for criteria.
• MSDN moved our Security Engineering landing page.
• We released Guidance Explorer which supports doing Security Inspections.  It includes collections of security inspection questions, security principles, patterns and practices.  See How To Use Guidance Explorer to Do a Security Code Inspection.

My Related Posts

• patterns & practices Security Engineering Explained
• Security Inspections
• Security Frame
• Security Innovation Security Engineering Study
• Videos: Security, Performance, and Visual Studio Team System

If you have to compete for resources or budget or sell an idea, one of the keys is a business case.  One way to think of a business case is "how big is the pie" and "what's your slice."  You use the business case either to argue for your project or in argument against other projects competing for the same resources and budget.

The Three Keys of a Business Case
Because the business case is such a critical piece of the project puzzle, I asked one of my mentors for their take on an effective business case.   Here's the keys:

1. Problem has to be apparent .  It's apprehensible.  As a stakeholder, I can attach to it.   It's real.  I relate to the examples.  I can see it, smell it, and can relate to instances of it.
2. Compelling benefit.  It has to be meaningful to the stakeholders (spell out what's in it for them.)
3. Clear path to return.  How do I realize the path?  When do I start getting paid? Cut my staff by 1/2 when?  What actions happen that are specific to the stakeholders ?

The Fourth Key
My mentor was on a roll and added an additional key: 

4.  Risk / reward "options."  The key is to be able to chunk down the value or the risk into an acceptable size (right-size the risk.)  For example "I like your idea, but it's too big a chunk to bite off."

My Related Posts

• User Experience, Tech Feasibility, and Business Value
• Time-Boxes, Rhythm, and Incremental Value
• Vision Scope Template
  

How do you design an org?  While there's lots of approaches, one of my mentors shared the 5 Ps approach with me.  To think about the org, you need to enumerate the 5 Ps to define the organization, the type of talent you need, overall organizational competencies, culture, etc.  If you don't know what you're trying to do, you don't know who to hire.

The Five P's
The 5 P's are:

1. Purpose: What problem are you trying to solve and for who? This has to be more than a mission statement.
2. Principles: This should touch on both the culture you want to develop as well as your guiding light in how you think about the problem you're solving and tradeoffs you will need to make. This should effectively establish your decision making framework on what tradeoffs you are and are not willing to make.
3. Priorities: Enumerate all the things that are important to you, now stack rank them to focus the organization.
4. People: Enumerate the types of people, competencies, experiences, and roles you need to support your Purpose. Quantify how many of each type you need.
5. Process: This defines the rhythm of your business. Do you do monthly, semi-monthly, or quarterly progress reviews? With what frequency does your "leadership team" meet to discuss issues? How frequently is your management going to check in on the organization. Note you should stay away from detailed processes like scrum vs. waterfall and other day-to-day implementation details.

It's one thing to get results.  It's another to articulate them.   Having a way to frame results can help both for personal learning, as well as review time when you have to reflect on accomplishments.

Commitment, Results, How, Evidence, Analysis

I've found framing results by listing the commitment, the results, the how, the evidence and the analysis to be pretty effective over the years.  I'm a fan of concrete examples, so here's an example:

One of the key experiences you get with Guidance Explorer (GE) is support for manual security inspections.   We call them inspections versus reviews because we inspect against specific criteria.   We supply you with a starter set of inspection questions, but you can tailor them or add your own. 

Security Code Inspection
We use three distinct types of inspections:  design, code and deployment.  For this example, we'll use Guidance Explorer to do a security code inspection of an ASP.NET application. 

Summary of Steps

• Step 1. Create a new View.
• Step 2. Add inspection questions to your view.
• Step 3. Save your View to Word.

Step 1. Create a new View. 
In this step, you add a new view to My Views.  To do so, in GE, right-click, My Views, and add a new View.  You can name your View whatever you like, but for this example, I'll name mine "Security Code Inspection."

Step 2. Add inspection questions to your view.
In this step, you add relevant security inspection questions.    To do so, in GE, click the patterns & practices Library, next click Security, next click Security Engineering, next click Code Inspections.  Expand the ASP.NET 2.0 set of security inspection questions.

For this example, drag and drop the questions from the following categories: Input and Data Validation, Forms Authentication, and SQL Injection.  This will give you a nice focused set of questions to drive your inspection.

Step 3. Save your View to Word.
In this step, you save your View as a Word doc.  To do so, right-click your view (e.g. "Security Code Inspection") and click Save Vew as ....  Name your doc (e.g. "My Security Code Inspection.doc") and click Save.

You just built your own security code inspection set!

Extending and Exploring
There's a lot of exploring you can do and ways you can extend:

• Design and Deployment Inspection: For example, you can try building a security design inspection set or a security deployment inspection set. 
• Code Examples.  You can add code examples and link them to your inspection questions.
• Agile Security Engineering.  If you're doing Agile development, you can scope your security inspection to a finite set of categories for a specific set of stories within the current iteration. 
• Patterns. If you're a fan of patterns you can add pattern examples to your design inspection.  At the end of the day, do what makes sense for you and your team to more effectively build software and meet your security objectives.

Share Your Stories
I'm sure you're bound to have stories.   If you haven't done security code inspections before, you're in for a treat.  Security Code Inspections are a proven practice.   While the criteria and context may vary, the technique pretty much remains the same.  Share your stories either in this post or send email to getool@microsoft.com.

My Related Posts

• New Release: Guidance Explorer is Now on MSDN

This is a significant release for Guidance Explorer (GE).  Our online "guidance store" is now hosted on MSDN.  To take advantage of this, you need to download the new version of Guidance Explorer (release 20071206)

What Is the Guidance Store
Our guidance store is a catalog of reusable guidance nuggets for helping you build applications.  The catalog is organized by the following:

• Types (e.g. principles, patterns, practices, guidelines, checklists, how tos, Q&A, app scenarios, code examples ... etc.)
• Topics (e.g. security, performance., project management, reporting, build, ... etc.)
• Technologies (e.g. .NET Framework, ADO.NET, ASP.NET, XML, SQL Server, Visual Studio Team System, Web Services ... etc.)
• Techniques (e.g. security inspection, performance inspection, threat modeling, performance testing ... etc.)

At a high-level, you can think of the catalog as a collection of application scenarios, "building codes" and engineering practices.

What is Guidance Explorer
Guidance Explorer is a smart client application that talks to the Guidance Store over a Web service.  You can use GE to create, organize and share your favorite guidance nuggets.

Key Usage Scenarios
The key usage scenarios are:

• Find relevant patterns & practices guidance.
• Build customized checklists for your development scenarios.
• Build customized guidelines for your development scenarios.
• You can build custom sets of guidance and share with your team as recommended practice.

To put it another way, you can use GE to slice and dice the patterns & practices catalog, tailor the guidance, or build your own guidance. 

What's New in the Latest Release
What you can expect in Guidance Explorer version 20071206:

• MSDN now hosts the guidance store (the guidance catalog is now hosted in MSDN labs)
• Improved catalog of guidance (it's more than 3,000 nuggets)
• Improved general usability, reliability, performance, and security
• Improved view structures in My Views and the patterns & practices Library
• Improved authoring/editing experience (tweaked the UI to feel better, improved reliability, fixed copy+paste from Word and added image support)
• Improved pushing down guidance types (if we do a new guidance type, you’ll get it now)
• Improved pushing down new views (if we change our views, you’ll get them)
• Improved deploying guidance stores (if you are a hosting your own guidance store, you can deploy it more reliably)

How's that for guidance as a service?  (Personally, I think the next step is relevant guidance feeds for guidance mash up scenarios.)

Getting Started

1. Download Guidance Explorer.
2. Unzip to a directory.
3. Run the .EXE file from the \bin file.

When you run GE the first time, let it synch for about 10 minutes.  It's downloading more than 3,000 items from our catalog.

Test Driving Guidance Explorer
Here's a few of the first things to try

1. Build your own playlist of guidance (create a new view under My Views and then drag your favorite guidance nuggets into it.)
2. Build your own guide on the fly (create a view of your favorite nuggets and save the view to a Word doc.)
3. Tailor an existing guidance nugget (double-click an item, click Edit, make your modifications then save to My Library.)
4. Write your own guidance (right-click My Library and add a new Item.)
5. Create a new focused library (right-click Libraries, click New Library, name your library then add some new items.)

Key Links

• Guidance Explorer Home
• Download Guidance Explorer release 20071206
• FAQ for Guidance Explorer release 20071206
• General FAQ

I created a recurring appointment in Outlook for Fridays.  It's a checklist of key leadership practices from The Leadership Challenge.  Each Friday, I scan this checklist and reflect on how well I've demonstrated the practices and where I need to tune for the upcoming week. 

Leadership Checklist 

Model

• Sets a personal example of what to expect?
• Makes certain that people adhere to agreed-on standards?
• Follows through on promises and commitments?
• Asks for feedback on how actions affect people's performance?
• Builds consensus around organization's values?
• Is clear about philosophy of leadership?

Inspire

• Talks about future trends influencing work?
• Describes a compelling image of the future?
• Appeals to others to share a dream of the future?
• Shows others how their interests can be realized?
• Paints "big picture" of group aspirations?
• Shows conviction about meaning of work?

Challenge

• Seeks challenging opportunities to test skills?
• Challenges people to try new approaches?
• Searches outside organization for innovative ways to improve?
• Asks "What can we learn?"
• Makes certain that goals, plans, and milestones are set?
• Experiments and takes risks?

Enable

• Develops cooperative relationships?
• Actively listens to diverse points of view?
• Treats people with dignity and respect?
• Supports decisions other people make?
• Gives people choice about how to do their work?
• Ensures that people grow in their jobs?

Encourage

• Praises people for a job well done?
• Expresses confidence in people's abilities?.
• Creatively rewards people for their contributions?
• Recognizes people for commitment to shared values?
• Finds ways to celebrate accomplishments?
•  Gives team members appreciation and support?

.

Our patterns & practices Performance Testing Guidance for Web Applications book is now available on Amazon.

• Buy the Book on Amazon
• Download the PDF
• Browse the HTML

Our patterns & practices Team Development with Visual Studio Team Foundation Server book is now available on Amazon.

• Buy the Book on Amazon
• Download the PDF
• Browse the HTML