The Importance of Guiding Principles (or, Key Decision Making Criteria)

At the heart of getting something done is getting everyone on the same page to move the project forward. This is especially relevant in an environment of a variety of individuals from department teams, and, ultimately, different walks life.

The diversity of views creates a challenge: Do we argue about the rightness or wrongness of ideas or a decision? Or, do we agree on a set of “guiding principles” and make decisions?

What is a guiding principle?

A guiding principle is a statement that summarizes a criteria or value-based mechanism. Let’s take the following situation in pricing strategy:

  1. Situation: Company X has developed a patented Water Retention System that helps trees grow faster, while using 80% less water.
  2. Complication: The founder and owner of Company X wants to target low-income farmers that cannot afford an expensive system. The venture capitalists wants the founder to charge higher rates to ensure maximum distribution, and ultimately a strong return on their investment.
  3. Question: How should Company X price the Water Retention System?

If you were in this situation, how would you facilitate a decision? Clearly, both the owner and the venture capitalists have a strong case to make regarding the rightness of their decision.

Option A: Conduct a pricing analysis, and present different prices and see if there is a price that meets both needs.

Option B: Develop a core set of guiding principles around making key business decisions, and then conduct a pricing analysis, and evaluate the options based on the guiding principles.

In Option A, there is an implicit debate about what the Owner and the Venture Capitalists value. In Option B, there is an explicit debate about what the Owner and the Venture Capitalists value.

Why is this important?

The point of this example is codifying the unsaid in guiding principles, each individual can evaluate what they value and see whether it resonates.

If there is resonance, then decision making and team dynamics can be more fluid (or, at the leaser — easier).

If there is not resonance, then decision making will be stalled and inauthentic — team members may grudgingly go along, but there will continue to be dissension as increasingly complex decisions are made, and the team will need to decide whether to continue together or not.

Originally posted on Karma Advisory’s medium page here.

Estimating Software Development Timelines

  1. Simple Project Estimation based on Requirements-Complexity: http://sanderstechnology.com/2014/a-simple-project-effort-estimation-utility/12854/#.WoRNYpPwYfM
  2. Agile Business Consortium Estimating Timelines: https://www.agilebusiness.org/content/estimating
  3. Best practices to estimate accurate ERP schedules, budgets in an ERP project: http://searcherp.techtarget.com/feature/Best-practices-to-estimate-accurate-ERP-schedules-budgets-in-an-ERP-project

Our Getting Things Done Cheat Sheet

One of my favorite books for product management and development is Rework by the folks at 37Signals. Here are some of my key takeaways that I always try to remember:

  • Quick wins: Get something done (even if it is really small), and move on to the next thing
  • Simplify, simplify: Keep solutions simple, don’t try to account for every potential issue that might arise
  • Long lists don’t get done: Long lists make you feel guilty and they never get done. Break one long to do list into a bunch of smaller to do lists
  • Break down your estimations: The smaller something is, the easier it is to estimate
  • Make tiny decisions: Big decisions are intimidating, and we usually put them off. Breakdown your decisions, so you can keep the momentum going
  • Checklists: If something is a repeatable process, make a checklist so you no longer need to think about it
  • Complexity = Simplicity + Noise: If something is ambiguous, breakdown the complexity into buckets

The Art and Science of System Generated Emails

One buzz word for the past couple decades has been “workflow automation.” As a technologist and someone who values efficiency, the intent of these ideas and the systems are important, but their implementation tends to get a little sloppy on the details.

One area where the rubber hits the road are system generated emails. Usually, a system generated email requires the user to take some sort of action, or to be notified of something. Here are some guiding principles that I recommend for developing a strong system generated email:

    1. Minimum Customization (i.e. variable copy): Since emails have to go through copyedit reviews, the communication departments, the legal teams, etc. — keep it simple. Less is more.
    2. Minimum HTML Formatting: The email has a purpose and really does not need too many bells and whistles — every added second to download to the users phone or computer reduces the chance of action.
    3. Consistency between Subject, Body and Footer: Humans proceess what they read in patterns. If the content is structured in a way to make it easy for the reader to understand, then there is a higher chance of response.
      1. Subject: [What does this have to do with?]:[What is the action?]
      2. Body: Identify Main Actor; State Needed Action; State Alternative Scenario and Action (if needed)
      3. Footer: What to reference for help? Who to speak with for help?
    4. Active Voice: All copy should be in the active voice

Thanks for reading.

~ Krishan