Wardley Maps for product development

Old school Wardley Map

Wardley Mapping is most commonly associated with higher level business strategy. When I’ve talked to people familiar with Wardley Mapping, they’ve been quick to dismiss it as a tool for the C-level suite, not for mere mortals developing products. I disagree. The following will attempt to explain why I find Wardley Maps not only relevant but vital to product development. If you’re unfamiliar with Wardley Maps, I recommend watching Simon Wardley’s 2017 Google Next talk for a good overview. If you want to take a deeper dive, I suggest Simon’s free online book.

Digital Beanie Baby: Husky
Welcome to the future. Digital Beanie Babies. Trade them on your favorite exchange!

Imagine. We’re transported to a time where it seems like anything with the label “beanie” is drawing attention, mostly because a new form of Digital Beanie Babies (DBB) has been skyrocketing in value for over 12 months. An entire ecosystem has sprouted up around the digital critters. In the midst of this beanie bonanza are exchanges launching to enable trading DBB, much like other exchanges exist for trading stocks, fiat currency (e.g. USD), etc. Each new DBB exchange has its strengths and weaknesses.

A few entrepreneurs identify an opportunity to create a new exchange that fills the gaps left by even the most successful DBB exchanges, while also adding a couple innovative features. They’re focused on meeting existing customer needs in a burgeoning market, not building a larger technical “platform” that has aspirations beyond being a very successful DBB exchange. The founders form their startup, get some technical people on board, build a proof of concept, raise funding, and continue building on the vision of providing a better DBB exchange for traders big and small.

But how does the startup know that they should build this product from the ground up?

Product development for this new exchange is focused on continuing the path the proof of concept set – build a secure, fast, trustworthy, and feature rich DBB exchange from the ground up. In such a new market space this seems reasonable. Put together a small, agile/lean development team and continue to build a product that meets the needs of its traders, validating the product as it is built. Lean startup style.

But how does the startup know that they should build this product from the ground up? Are there pieces they should buy? Higher level functional open source components they should adopt? The assumption is made that because DBB trading is a fairly new market it requires building a brand new product from scratch. Besides, many of the most successful DBB startups built their exchange from the ground up. They blazed a trail, this new startup is simply following in the path that’s cleared for them.

Enter Wardley Maps, a way to visualize the evolution of the underlying landscape anchored to the needs of users. When we map out the Digital Beanie Baby trading landscape, including high level components/requirements of a DBB exchange, we start to see that a number of core components of the exchange are available for purchase, leasing, and/or open source. After all, exchanges have been around quite a while in various forms.

Based on the product development approach the Beanie exchange startup is taking, we’d expect to see most of the exchange components and requirements in the “Custom-Built” or “Genesis/Novel” lane, but instead a majority of the core exchange features in development (highlighted in blue) fall into the “Product/Rental” lane or very close to it. What does this tell our startup? It’s telling them that the bulk of what they’re currently developing is something that has (probably) been built before and is available to buy, lease, or simply use (open source).

A common objection I hear at this point is: OK, but what if you’re wrong about the position of various items on the map? That’s quite possible. The potentially incorrect map positioning can drive meaningful discussions as well as further research to either validate or invalidate the position. The beauty with the map is that we’re: A) having the product/business strategy discussion based upon a shared visual aid and context B) able to identify our assumptions. In the case of our startup example, the biggest areas likely up for debate are core components (that they’re creating themselves) like the matching engine, order book, API, web app, etc. Maybe with some further digging the discovery is made that commercial offerings exist, but they’re immature, or expensive, or rigid, or any number of other issues that may make them less viable as options. Maybe we find that certain components are available as products, but are only really suitable for more traditional exchanges, not for those aimed at trading digital beanies. It’s also possible that we discover there are numerous existing components and products that fit our needs and validate the position of those items on the map.

The Wardley Map provides a higher level view that can help drive lower level product development decisions.

Another objection I’ve heard is that what I’m crediting to Wardley Maps is really just another path to market research that any business should already be doing. Possibly, but the map provides a shared context that market research does not commonly provide, as market research tends to end up buried in docs and slide decks. A group of people can look at a Wardley Map together and start to quickly identify areas of alignment, disagreement, opportunity, etc. Those with more industry expertise can be brought in to look at the assumptions on the map and determine if those assumptions are on track or need adjusted.

In our startup’s case, the map identified some potential blindspots in the product development approach. Should the exchange startup be building something from the ground up that is already available for purchase, rent, and/or adoption? Unless the devil is hiding in the details of those components mapped in the product lane, then it’s unlikely the startup should pour further (fairly limited) development resources into those items. 

It makes more sense for the startup to consider focusing its development time and talent on building items in the novel or custom lanes. Or, possibly focus the engineering team on implementing the items in the product lane, become experts on operating those in production (much sooner than the homegrown equivalent would be available), and then discover through real customer feedback what should be introduced on the exchange next. The possibilities the map opens up are much greater than what development teams tend to consider when they’re building a product, such as, should we: Scale back feature X, Y, Z? Reprioritize the backlog? “Pivot” to target only one subset of customer initially? Change our approach to development in order to increase velocity and lower time to market? Reset some or even all of our goals for the MVP? Those are all legitimate options to consider in product development, but they may be too nearsighted and ultimately limiting. A startup is particularly sensitive to this form of myopia, as the business and product the startup is building are so tightly coupled, it can be hard to determine where one ends and the other begins. The Wardley Map provides a higher level view that can help drive lower level product development decisions.

Adding Wardley Maps to a product development team’s toolbox is a valuable asset, even if at a first glance it’s hard to understand how. Mapping is not a silver bullet or even a tool that is immediately easy to grasp, but it’s worth learning. This example only begins to touch on all the nuances of Wardley Maps. There are many other nuggets of strategy gold to be found for those who take the time to learn how to create and collaborate with these maps.

A remote retrospective

It’s been a while since I last facilitated an all remote retrospective. Below is an email I sent out to the team I’m currently working with to help us prepare for our first “retro” together. We’ve since held the retro and it went well overall, so I thought this prep and guidance might be useful for others to iterate on.

—–

Hi All,

On Tuesday we’re going to have a Project Retrospective (aka “retro”). In my experience, retros are hugely beneficial opportunities for teams to learn and grow.

Please take the time to read the rest of this email. It outlines how the retro will run. In order to make the most of our time, it’s best to come prepared. :-)

Retro Goals

  • Learning jointly – From each other’s different perspectives, feelings, and current thoughts about where the team is at since launching the project.
  • Taking action Based on learning together, we identify where we can most benefit from improvement and take action.
  • Strengthening the team – We’re in this together. By listening, learning, and taking action on what we’ve learned, we develop a stronger bond that is bigger than “just the work”.

Ground Rules

Regardless of what we discover, we understand and truly believe that everyone did the best job he or she could, given what was known at the time, his or her skills and abilities, the resources available, and the situation at hand.

  1. Be respectful
  2. Be present (no phones, no “side chats/conversations”, no browsing, etc.)
  3. Everyone gets a turn to speak
  4. No interrupting
  5. No judgement on feedback (use “I statements“)

Before The Retro (between now and when we meet)

Please take time between now and when we meet to think about the following in relation to your experience and/or what you observed during your time with the TGE project:

  • What you want us to continue doing
  • What you’d like us to start doing
  • What you’d like us to stop doing

You can add your items to this doc, which we’ll use as part of the retro: Google Doc

The Start

Check-in: We’ll go around the call and have everyone provide one word for how they’re feeling in the moment. Have trouble coming up with a word for how you’re feeling? I know I do sometimes! Try this to help identify a word: https://verbaliststravel.files.wordpress.com/2016/01/the-language-and-vocabulary-wheel-for-feelings-verbalists.jpg

The Middle

Part 1) We’ll use the “Before the Retro” section above to guide the initial discussion. What we want to: continue, start, and stop doing. If you haven’t added your items to each area, we’ll have a short time for everyone to add to each list.

Part 2) We’ll go through each item and open it up for questions/clarification. I will do my best to encourage open, focused discussion that honors our time.

Part 3) Everyone gets 3 votes per area to put against the items they think we should take action on now, not later. You can apply more than 1 vote to an item if you feel that strongly about it.

Part 4) Identify the top item in each area and determine next steps (which can be as simple as identifying an owner to drive the action post-retro). …But what about the other items – aren’t they important too? Yes! But focus is key. Just because an item isn’t made “top priority” doesn’t mean it won’t see progress in the future.

I’m accountable for ensuring the 3 items we identified to take action on make progress. Don’t expect miracles. Some things require a a fair amount of determination over a period of time to show results. My commitment is to continue to provide visibility to the items and help move them forward. Expect this to be part of our weekly meetings, even if it’s just a quick update.

The End

Check-out: Everyone on the call gets a brief (30 seconds or less) opportunity to express closing thoughts/feelings now that the retro is at a close.

Looking forward to learning and improving with you all!

Josh

An example of delighting customers

Netflix is amazingly good in a lot of ways. Add this one to the list:

Netflix email screenshot

Netflix could have sent me Back to The Future and made me wait 3 to 5 days for it to arrive, but instead they sent an additional disc from my queue to make up for the shipping delay. They didn’t have to do this and I wouldn’t have complained. But they did and I think it’s a nice touch that deserves recognition.

Agile and Estimates and Contracts! Oh My!

Over the last six months, I’ve been mulling over one of those subjects that has often been a stumbling block for IT providers considering adoption of agile for their customers’ software development projects. The dilemma revolves around contracts and estimating projects. The two tend to go together. Once you have one figured out it seems you’re left with even more questions with the one remaining. I have some ideas on how to make agile contracts and estimating better based on what I’ve learned and observed over the years.

WARNING: This is a long post. I try not to write long posts. I think this one is worth it, mainly because it’s building off the ideas of those much smarter than me. Continue reading “Agile and Estimates and Contracts! Oh My!”

Be Great or Quit Now

I spent the day today with my fellow Gestalt Scrum Masters meeting about what we want to accomplish as a team within the company. It was a productive meeting overall. There were quite a few good discussions that have led to some meaningful action items. I’m looking forward to the weeks ahead.

The Dip on Amazon.comWhen discussing our vision for the Scrum Master team within Gestalt I went on a (slight) rant. I couldn’t help it. I read Seth Godin’s book, The Dip, while on the plane last night and one idea hasn’t left me: Be great, don’t settle for anything less. Don’t waste your professional life in pursuit of anything less than greatness. You can be mediocre anywhere, anytime. Quit when you’re headed for a dead-end. Quit when you’re headed for a cliff. Only pursue those opportunities that provide the opportunity for greatness.

Greatness at Gestalt is no small feat. We’re providing software and consulting services to the Department of Defense. The DOD can no longer afford the status quo of paying big bucks to big companies that take many years to deliver mounds of paper and little of value. The DOD’s “competition” these days doesn’t thrive on big budgets, big monolithic organizations or deadlines in the far off future. The DOD’s “competition” thrives on constraints, is massively distributed and constantly seeking payoffs sooner rather than later. Greatness at Gestalt is delivering the right technology solutions quickly and in an open, non-proprietary manner so that the DOD can succeed in an ever changing environment.

Number One ButtonScrum Master’s play a big role in helping Gestalt as a whole reach greatness. It’s not because we are more important or talented than anyone else within the company. The role we play within Gestalt is one of leadership on a variety of levels; serving as change agents that touch many different areas within the company. We are only a piece to the puzzle called greatness, but if we don’t do our jobs well then there are many others that suffer as a result and the puzzle is incomplete. Not being great as Scrum Masters at Gestalt is not an option. As Seth Godin says on page 57 of The Dip: If you’re not going to get to #1, you might as well quit now.

Attack of The Resume

Is your resume really long? Is it chock full of never ending prose? Does it cover every job you’ve held since about the age of ten? Does your resume lose YOUR attention three sentences in? Take heart, you’re not alone.

I’ve noticed a trend in tech resumes over the years. They tend to be extremely long, boring and short on anything I would consider informative. Earlier this year I swear I had a twenty pager in front of me. I wouldn’t mind it so much if people wrote overly long resumes that read like a decent novel, but most of them are bordering on nonsensical due to poor grammar and horrendous formatting. My designer friends would cry if they saw the abuse of typography committed by some of the resumes I’ve had to review over the years.

Enough criticism, now onto what I’d like to see in a resume. I really want to know what you’ve accomplished in the past. Accomplished, that’s the key word there. I don’t care about what you did day-to-day at your job. It’s nice to know that you did everything from re-engineer the next Pet Store app to water the company’s plants, but we can talk about that later. I care about answers to questions like: What have you done that has made a positive difference? What were you able to make happen that delivered value to your customers? If you can communicate that on your resume, then you have just put yourself in the top 20% – easy.

A Bastion of Customer Service: Home Depot

Looks like Seth Godin has noticed the same stellar service at Home Depot that I have of late. Mind you, I’m not hanging out at Home Depot much, but the last few visits have been filled with frustration. Aisles are a mess, shelves are even worse, and the checkout clerks take “it’s not my problem” to a whole new level.

The best is when my Dad and I were ready to pay for a few items at the local Home Depot here in Joplin, MO. I suggested we go through the self-checkout. My last experience at this Home Depot told me that the counter intuitive self-checkout machines were a safer bet. My Dad spotted a clerk with an open lane so it was too late. He approached the register and asked the clerk how he was doing. The guy replied with, “I’m pretty pissed off right now,” raises his voice, “See that girl right over there at that register? She’s telling me what to do. She’s only worked here one week and she thinks she knows everything.” Uh-huh, OK. Thanks for sharing buddy.

Sigh.