Words and pictures

This is part of a series on “I believe in…”

Early on in my work as a software developer, it became clear to me that communication was one of the biggest barriers for a team to create something valuable. Communication comes in so many different forms (many of which I believe have been unfairly maligned), and as a developer, I wanted to understand each of them and leverage them to their greatest potential. I read The Mythical Man-Month by Frederick P. Brooks, Jr. and was flabbergasted at the amount of communication that went into the OS/360 project that he references through the book. Looking at the small team of developers that I worked with, the level of communication Brooks wrote about seemed crazy. Yet, it resonated with me.

I believe in writing things down. I believe in drawing and diagramming as a tool to develop a better understanding.

So, I tried to get my team on-board with more communication. We had tools for communicating, but they weren’t really used. For the most part, we took a stack of ideas written in a Word doc from our boss (who played the role of a product manager) and then we huddled together to divvy up the work, only coming together again to discuss the interfaces between one person’s work and the other, and mostly after the work was already “done.” Bugzilla was a joke, the fancy tools we had from Microsoft and Rational Rose were haphazardly used, if at all, and testing, let alone test plans, were almost non-existent.

I was determined to “lead by example,” creating documentation to spur my colleagues into communicating more. My reasoning was: if I created these artifacts to share, shared them, then brought us together in meetings to discuss, then we would improve communication. Right? I was going to validate my specs and designs with peers before I built the wrong thing, and I was going to have us work more as a team.

I wrote specs. I made Use Case Diagrams. And Sequence Diagrams. And Entity Relationship Diagrams. I setup a list-serv for the team. I tweaked VSS to require commit comments of a certain length. I added fields to Bugzilla to capture more detail. I even tried to make Gantt charts to show the dependencies we had between each other over time.

And maybe we worked better as a team. Maybe not. This was early in my career, and it’s hard to say if the communication I tried to foster made a difference to others, or to our output. And, this was 20 years ago, so my memory may be a little hazy.

And, learning that “communication is important for teams” isn’t really a ground-breaking discovery.

Books: The Unified Software Development Process, UML Distilled, The Mythical Man-Month, and Drawing on the Right Side of the Brain

What I did learn was that writing it down, drawing it, diagramming it – those activities were more valuable than I ever thought. It brought awareness to problems I had not yet perceived, and forced me to move from my abstract mental visualization of a solution into something more concrete. Spending 15 minutes trying to translate my ideas into something constrained by a whiteboard’s two-dimensionality and only 4 marker colors actually helped me solve problems better and faster.

And it didn’t matter if anyone ever saw those diagrams or not. The value was in practicing the translation of an abstract idea into something concrete, with all of the physical constraints that that concrete form imposes.

Only when one writes do the gaps appear and the inconsistencies protrude. The act of writing turns out to require hundreds of mini-decisions, and it is the existence of these that distinguishes clear, exact [ideas] from fuzzy ones.

The Mythical Man-Month – Frederick P. Brooks, Jr.

Neuroscience is not something I really know anything about. But, maybe it is similar to what Betty Edwards found and shared with us in Drawing on the Right Side of the Brain. Maybe that simple act of forcing both hemispheres of your brain to try to solve a problem helps software developers and engineers build the right thing faster.

Lastly, my belief in writing and drawing does not apply to just software development. Any process, any system, any organization, any abstract concept can be better known to you by trying to turn it into language or an image.

I believe in writing things down. I believe in drawing and diagramming as a tool to develop a better understanding. An audience is not required to make this act valuable. The more abstract the “thing” is (like software architecture – it is much more abstract than, say, the framing of a house), the more value there is in diagramming it.

Software Development Life Cycle and Value

This is part of a series on “I believe in…”

The value of the software we create is defined both by time and usefulness. Almost every marketplace is full of big and small competitors looking to bring something more useful to prospects and customers every day. When the application is integral to the value proposition of the entire organization (i.e., part of the product sold to customers), it must be able to grow and change in response to the needs of its constituents and stakeholders, and to maintain or accelerate differentiation from competitors. You need a process to effectively manage this life cycle, and that process, and how you execute it, are key to the product’s success.

I believe in Agile and Scrum as a tool to create a more valuable asset that can meet changing demands more quickly. The application or platform is never “done”. We have releases of the software to satisfy current need and position something new and compelling to customers and stakeholders. And then we learn, respond, and release again.

I strongly believe in verifiable and measurable results. Code can be tested to make sure it functions how the developer wrote it (and to challenge assertions), and an analyst can validate that what the developer wrote is what the feature spec said. But to produce high-quality applications, we must also test that the specifications meet the requirements, and the requirements meet the customer expectations, and the software meets the needs of the market. Just as I expect for each developer to test her or his code, and to do so in small, fast iterations, I also expect the same of the Product Owner function (which is connected to Product Management). Through identifying users, actors, and personas, then developing user journeys and validating those user journeys with mock-ups and prototypes, we can get much more certain that we are developing the right solution before committing huge amounts of effort and money in the wrong direction, or even in a direction that is just a degree or two less than optimal.

DevOps is an integral part of recognizing the value of Agile. DevOps provides the framework for quality and consistency (in part through Continuous Integration testing), production readiness and deployment, and monitoring and optimization.

Thus, I believe that the Software Development Life Cycle is equally important, and inextricable from the actual code and product itself.

Pricing takes empathy

I got a reminder last night about how self-centered pricing can be. I know that I have fallen victim to being a bad pricer, sinking into the lazy cost-plus model. But that is not the best way to price for you, or for the buyer*.

Pricing takes understanding and empathy. To set the right price for the right customer, you must understand what problem the customer is trying to solve. Why does this problem exist, and how does this problem cost the customer? You must know your customer and market – you must think about it from their perspective.

If I have a problem that is costing me $100, and someone has a solution that costs me $90 (including my own switching costs and opportunity costs), then I would be foolish to not take it. If I trust the solution provider based on all of the signals that I might use to establish credibility, like market authority, brand promise, reference checks, or an inspection of their solution, then I would gladly pay the solution provider for that product or service.

As the buyer, it doesn’t really matter if it costs the solution provider $5 to deliver, or $95 to deliver. I am still saving $10. That is the Value in this transaction.

That price, $90, is a Fair Price if both the buyer wins, and the seller wins. A win-win! The seller wins if it makes a Profit (price is higher than cost). The Buyer wins if it gets Value from the purchase (price is lower than buyers costs without the product or service).

Price, value, and profit diagram

We live in a complex world, where an infinite number of factors impinge upon the “true” cost of a buyer’s problem, and the “true” cost of the seller’s solution. For example, a lot of value in the product or service is in the buyer knowing that the solution provider will be there over time. I am not going to by insurance from someone that has told me they are going out of business next week. The value of that, and so many other factors, is hard to measure. (And, this is where Brand plays such an important role in establishing Fair Price!)

But if you can put yourself in the customer’s shoes, understand why it is going to market for a solution in the first place, and work with that customer to address their needs, then you can get to the right price.

Simple Steps:

  1. Ask your prospective customer/market what problem they are trying to solve.
  2. Ask “Why?” a couple of times. Get to understand what that problem is costing them in terms of real money, time, lost opportunity, lost growth, focus, and maybe even happiness.
  3. Understand your own costs – and all of the costs (like opportunity costs).
  4. Aim to meet in the middle, create a Fair Price that is a win for the customer, and a win for you.

* That is, unless your brand promise is based on some order of scale and volume, like Amazon or Walmart. But even then, I would argue that retailers like Amazon and Walmart set price based on market value, not on the cost of the product they are selling.

Originally published on February 8, 2018 as Pricing takes empathy on LinkedIn.