The Product Mindset: Your Secret Weapon is Value

The Product Mindset: Your Secret Weapon is Value

The Product Mindset: Your Secret Weapon is Value

Written by
On March 18, 2021

This is the third in our series of posts on The Product Mindset. See the first post in the series here: The Product Mindset.

As we’ve explored throughout this series, a surefire way for companies and teams to improve their value to their customers and align their own priorities, mission, and working cadences is to cultivate a product mindset.

This is the set of attitudes, beliefs, and behaviors that is concerned with building your business by building great products in response to the needs and desires of your customers or other users. A product mindset prioritizes outcomes, learning, understanding of users, and total system health. It’s an approach that pairs neatly with agile development models.

My SDG colleagues and I have had the pleasure and responsibility of working with teams and customers across industries and contexts. One observation I’ve made is that working teams at the ground level are generally willing to try new methods and approaches, like a product mindset.

But even the most willing and progressive team may be fighting hidden forces. These forces can hinder good product practices for even the most collaborative and productive product team. In effect, the team is paddling against a current, and it may not even know it.

The hidden, internal forces

It looks like this: teams of engineers, product managers, and designers might be excited about product-led, customer-centered, learning-driven approaches. They are happily collaborating to shape a compelling vision, break that into its key themes, align discovery and development work to those themes, and build a measurement framework that connects their daily work to their business performance. They’re excited to pursue value and satisfy their users.

And yet, someone on the team, maybe a scrum master or a mid-level product manager, will utter sentences like: “uh, no, I don’t think we can prioritize that valuable thing, we are committed to this other thing instead” or “we’ll never get that approved ahead of this.” It’s as if something is keeping them from working in the productive, customer-driven, agile way that they want to work.

In my experience, more often than not, the problem they’re running into is at the uppermost levels of approval and investment within their own organization.

To understand this, consider the way many companies govern the work of their technology teams. Usually, there are executive systems that control which technology projects are even started. These processes often happen at annual planning and budgeting levels, on relatively long (quarters to years) cycles. They look like an estimating, budgeting, prioritization, and approval exercise, all designed to ensure the right work gets funded. Requirements, estimates, and rationale are made into a business case, complete with costs, usually by a sponsoring executive. And then a leadership team decides which costs are worth incurring. The decisions are based on estimated return on investment (ROI), and on which sponsor makes the most compelling case.

If the work is approved, the product team is then on the hook to deliver the thing it promised during this funding and approval cycle. But some people on the team may not even realize this origin story, and the obligations this system puts on the product team.

When working with executive sponsors who might be gathering information for planning & funding processes, don’t focus on the things you’ll make. Instead, focus the conversation on value you’ll produce.

Change the conversation to value

To be clear: no one running these budgeting and planning processes wants to hamper a team’s ability to deliver value. Usually, these systems involve astute leaders, often at the helm of the organization, who are charged with ensuring the overall success of the company. I have no doubt that they want to make good choices. But they may have backgrounds and motivations that emphasize certainty over a product-driven, learning-driven attitude. Such leaders can be instrumental in helping a product team succeed, but they also need to manage a whole host of executive concerns, like investors, sales performance, regulatory affairs, PR, competitive threats, which aren’t necessarily amenable to your product mindset.

And that’s OK. As a product leader, you’ll do well to recognize this dynamic, and to navigate it with maturity, clarity, and communication.

Our best suggestion: when working with executive sponsors who might be gathering information for these planning & funding processes, don’t focus on the things you’ll make. Instead, focus the conversation on value you’ll produce. Here are some specific techniques.

  • Involve leaders in developing a well-articulated product vision and value proposition. Share your vision early. In fact, ask your leaders to help. Many executive leaders are quite skilled at writing vision statements and articulating value propositions, and their vision will be instrumental in the success of the product. Then use their vision to shape the deeper work of the product team. By doing so, it’ll be easier to explain your choices and recommendations upward, since the leaders already have the context of the value proposition.
  • Design and track metrics tied to your vision’s themes. Ask executives: what customer behavior or metric would make you feel good about our technology products? Then, connect your product work to those metrics. Don’t fixate on “building a portal”; prioritize “improved customer engagement,” for example. The portal might be just one way to do this. By doing this, you’ll move beyond questions about feature delivery to conversations about the value of those features.
  • Reinforce your product-driven approach. Explain how you’ll drive those metrics through relentless discovery of functionality and experience. Reframe their desire for certainty about deliverables with a focus on uncovering what’s meaningful to customers and the business. In such a dynamic, the teams — not the executives — are then responsible for producing value through functionality and for reporting back results.  Explain that effective teams might run multiple experiments, shut down things that don’t appear promising, accelerate things that do.
  • Celebrate small successes. In some organizations, becoming product-led may take years of work and change. Don’t get discouraged if all you’re able to do during this cycle is, for example, get the IT delivery manager to build time for discovery into the project plan. That’s progress!
  • Commit to clear communication. Above all, promise your leaders that you’ll regularly report on the results you’ve achieved, in the language of the metrics you’ve prioritized and the value proposition you’ve agreed to. Then, keep that promise.

One last thing — and this might be a bit dangerous. Even if your company’s annual planning cycles seem committed to prioritizing and approving certain projects, with specific deliverables, remember that these projects usually aren’t what your senior leaders really want. They want the outcomes represented by those projects: revenue, growth, satisfied customers, competitive differentiation. They want value.

So even if they have approved and funded a project or a feature — say, “build a new portal site for managers” what they really want is the outcome, the value that the feature expressed. If you can translate those items to value,  you may be able to get away with delivering something else, like, in this example, creating a new manager view for an existing site.

With good communication, and perhaps a bit of charm (one of the most important soft skills of a product leader), you’ll satisfy your leadership, start paddling with the current and, more importantly, delight your users and build a great product.

Photo credits:

Kayak paddling upstream photo by Tim Foster on Unsplash
Opening door photo by Jan Tinneberg on Unsplash

The Product Mindset

insights

The Product Mindset: It’s Your Users’ Product

insights

SDG Consultant Co-authors North Star Playbook

insights

In Progress and the Curse of Reductionism

In Progress and the Curse of Reductionism

In Progress and the Curse of Reductionism

Written by
On March 16, 2021

The power of a two person team

My colleague and I, unsatisfied with the status quo and intoxicated with the power given to us in our two-person team, began assembling the most authentic Kanban board we could come up with. We started simple, with Backlog and To Do. We added In Progress and Done. Then we got bold. We added a column for Testing and UAT. “But,” I said, “isn’t that just a part of in progress?” 

With the dam burst, we found ourselves staring at a Kanban board with 17 columns. What started as a serious exercise quickly turned to a fun one, but something dramatic emerged from the silly board we had assembled. All our additional columns were flavored as “In Progress,” but they were legitimate statuses one could find their work in, such as Roadblocked and Reworking. 

The In Progress column serves an important purpose. It lets high-level viewers know that a task is being worked on. It provides a quick glance into the activity of the team. But the concept of boiling down all the work that goes into a single item in a status of In Progress can feel overly reductionist, especially to the person doing the work. 

 

One little box

As an analyst, I tend to find myself assigned to SPIKE stories. I get a timebox (fancy!) to figure out how a particular process works. I spend hours interviewing people, shadowing, browsing documentation, making beautiful diagrams — and then I get to sheepishly move a little box from the left to the right, about an inch, to announce to my Product Owner that I am done. It’s very anti-climactic. 

Complex processes can be reduced to simple representations; we all know this, and we all know there are significant benefits to be gained from those representations. But don’t let the simplicity of that In Progress column ever detract from your feeling of accomplishment — don’t ever let it make you feel unjustified in your frustration when something isn’t working, or when you hit a dead end and don’t know what to do. 

How do you accurately reflect the work?

Allow me to share some of the columns we came up with in an attempt to truly report on the status of our tasks. 

We started with Roadblocked, one of our legitimate contributions (before the sillies set in) to our “In Progress buffet.” We’ve all been there. We’ve all felt the dead-end looming over us. This was, of course, followed easily with Roadblocked Again. Clearly, this is where the aforementioned sillies began. Roadblocked Again sounds like it would be the same to the inexperienced, but I would challenge anyone who has worked on a project to tell me that hitting your second dead end feels the same as hitting your first one. 

We added the one-two-three-punch — I Think I’m Done / I Was Wrong / Reworking. You’ve finished. You met the requirements or the acceptance criteria. You’ve tested. It makes sense. You’re happy. You think you’re done. And then someone has to deliver the bad news: you were wrong. After you’re done playing the “blame somebody else” game (my personal recommendations are “the requirements were wrong” or “the request was stupid”), it’s time to accept your mistake and move on. Time for rework! 

Every Kanban board should include the column Meetings About Roadblocks. We all have to do this. You’re not alone. 

Celebrate the victory of the little box

We came up with many more, each funnier than the last I assure you. But our board eventually conformed to the norms we’ve all come to love, and we kept it all wrapped up in a traditional In Progress column. It may have taken a silly turn, but it became very clear to me as we developed our super Kanban board how much baggage we pack into that single In Progress column. Every hard-worked minute spent on fixing bugs or implementing new features gets tracked there. For the simple tickets, it’s perfect. But for the intense time sinks, where we lose hours — sometimes days — to frustration, roadblocks, ambiguity, and pounding our fists into desks, In Progress just doesn’t quite do it all justice. 

I vowed to take a few steps to make sure I respected the curse of the In Progress column. Every ticket, no matter how simple or easy to resolve, was treated almost like its own mini project. Every time my developer finished an item, we took time to celebrate the victory, even if it was just a brief conversation to reflect on how much I appreciated his work, or what I could do better to make the next ticket go even better. It was a small step in the project, but I worked hard to appreciate the emotional process that accompanies each and every ticket. 

Conclusion

The curse of “In Progress” is very real. As an Analyst, I’ll remember it when I feel disheartened watching my colleagues plow through stories every week while my large SPIKE stories sit in the same column for days at a time. As a Scrum Master, I’ll remember the curse when I’m wondering why my team has issues sitting in that column for what feels like too long a time. But most importantly, I’ll remember that the simple act of moving a task into Done is often deserving of a lot more praise than that quick action would lead you to believe.

Related Posts

Software Development with Agile Hybrid Projects

insights

What a Technical-Minded Scrum Master Brings to the Table

insights

Preparation Tips for a Virtual Interview

Preparation Tips for a Virtual Interview

Preparation Tips for a Virtual Interview

Written by
On February 25, 2021

Be prepared for something new

Seeking a new job can be a stressful and time-consuming process. A virtual job search, though, is a new experience even for a seasoned job hunter. Virtual interviews are becoming more common, and while many of the old interview tips still apply, here are some tips and tricks from the SDG Recruiting team to set yourself up for virtual success.

 

  1. Make your on-camera background and lighting reflect your style – but not distract from you as the interviewee
  2. Determine which platform is being used for your virtual interview – then download and test the platform for video and sound quality prior to your interview to ensure you’re ready 
  3. Dress to impress – Even though you are not in-person, the interviewer can see how you are presenting yourself 
  4. Reference guide –Have your resume, the job posting, questions for the interviewer, and the company website handy to reference 
  5. Plan – Ensure that potential distractions like your phone, pets, kids, etc. are taken care of  

Interviewing may have changed, but if you’re ready to explore new opportunities, we hope these tips help you be successful in your virtual interviews.

 If you are a passionate technologist looking for your next position take this chance to learn more about SDG: https://solutiondesign.com/careers/

 

Spring and Spock: Happy Together

Spring and Spock: Happy Together

Spring and Spock: Happy Together

Written by
On February 18, 2021

Things change for the better

About four years ago I wrote a blog post describing how to use Mockito to mock dependencies within a Spring test.  You can find that blog post here: https://solutiondesign.com/insights/spring-and-mockito-happy-together/.  In the last four years a lot has changed.  There has been a rapid growth of new technologies, frameworks, and tools.  One of those new frameworks is a testing framework called Spock.  Spock has been around since 2008 but has seen a wide adoption in the last number of years.  Spock tests are written in Groovy and Spock uses Junit as its test runner under the covers.  

Spock includes the ability to mock dependencies natively without including a separate mocking framework such as Mockito.  This post will not cover how to write a Spock test as the online documentation for Spock is excellent.  For a quick overview of Spock that can get you up and running quickly, see the Spock Primer in the References section below.   

Here is an example test that mirrors the same test in the Spring and Mockito blog post but using Spock instead of JUnit and Mockito: 

 


The above test is a unit test where the method under test is the AccountService createNewAccount method.  All dependencies of the createNewAccount method are mocked as you can see at the start of the test.  The given: block sets up data for the test, the when: block executes the method under test and the then: block is where assertions are made to validate what happened.  Notice the absence of the assert keyword used in JUnit.  The assertion is implicit  each line will fail if the expression is false and pass if the expression is true.  It is beyond the scope of this post to go into detail on each assertion in the test.  However, I would like to highlight the accountDAO.save(_) assertion.  Spock will make the argument passed to the save() method available in a closure that follows the method call and it can then be validated in the closure (where the assert keyword does need to be used).  After the argument is validated, the persistedAccount object that was created at the start of the test is then returned from the mocked save() method call. 

As discussed in the Spring and Mockito blog, there are times when you want to write a test that loads the Spring application context to validate that the Spring autowiring is working as expected or, for example, to validate that the data access code works to write to and read from the database.  This is simple with Spock.  All you do is include the Spock Spring module as a dependency in your build script.  Spock’s Spring module enables integration with the Spring TestContext Framework.  Then when you include an annotation on your test that is recognized as a Spring annotation such as @ContextConfiguration, @SpringBootTest, or @WebMvcTest, the Spring application context will be loaded and Spring beans will be available in the test.  Below is an example Spring test that is used to test saving the Account entity to the database and mirrors the same test in the Spring and Mockito blog post: 


You can see in the test above that the AccountDAO and the EntityManager are both Spring managed beans that are injected into the Spock test.  An H2 in-memory database is used in the test to validate that the Account entity object can be saved to the database and read back out. By using a Spring test instead of a Spock test, the actual Hibernate mappings and underlying database queries can be tested. 

But what if you want a Spring test to test a service method but need to mock one of the dependencies of a service?  Maybe this dependency makes a call to a third-party system that you cannot guarantee is always available.  With the wide adoption of cloud-based providers such as AWS, you could have a service that calls out to S3 to retrieve data and you do not want to manage AWS credentials for authentication in your tests.  This is also easy to accomplish with Spock.  Below is a Spock test where the AuditService is mocked but the AccountService is not: 


This test mirrors the Spring and Mockito test in the Spring and Mockito blog post.  It is a Spring test because we want to also validate that the Spring Security configuration is correct.  Spock’s @SpringBean annotation causes the mocked AuditService to replace the AuditService that was originally present in the Spring ApplicationContext. The assertion 1 * auditService.notifyDelete(accountId) validates that the mock audit service’s notifyDelete method was called exactly once with the expected accountId. 

The sample code for these tests can be found here.  If you view the sample code, you will notice the detailed and somewhat complex JPA spring configuration and that this is a non-Spring Boot project.  An effort was made to keep the code as consistent as possible with the code from the previous blog post except for upgrading libraries and using Gradle instead of Maven.  If starting with a new project, I would highly recommend using Spring Boot.  Most of the configuration would not be needed as Spring Boot automatically configures Hibernate as the default JPA provider and starts an embedded H2 database if the H2 library is found on the classpath.  The @SpringBootTest annotation also comes with a lot of functionality and makes Spring tests easier to write. 

I hope this article is helpful in demonstrating how to use Spock and Spring together to create clean, flexible, and powerful tests.  Please see the references below for more information and examples. 

References 

  • http://spockframework.org/spock/docs/1.3/index.html 
  • http://spockframework.org/spock/docs/1.0/spock_primer.html 
  • http://spockframework.org/spock/docs/1.3/module_spring.html 
  • https://www.baeldung.com/the-persistence-layer-with-spring-and-jpa 
  • https://docs.spring.io/spring-framework/docs/current/reference/html/testing.html 

The full source code used for this article can be found on our git repository. 

The Product Mindset: It’s Your Users’ Product

The Product Mindset: It’s Your Users’ Product

Insight

The Product Mindset: It’s Your Users’ Product

Written by Jason Scherschligt
On February 8, 2021
This is the second in our series of posts on The Product Mindset. See the first post in the series here: The Product Mindset.

Several years ago, one or another of my daughters (I have three) said, “Whoa. Dad has an Instagram?”

First of all, my Instagram account is utterly unremarkable. I mostly use it to look at interesting art and photography to soothe my weary soul. My digital media consumption is not the point of this story.

No, what struck me about my daughter’s statement was the relationship it proposed between me and the product: “Dad has the product.” Not “Dad occasionally engages with the features of this product.” Not “Dad maintains an account on an application provided by a company.” In Dad has an Instagram, my daughter proposed a more substantial relationship between the product and its user. The product, in this wise formulation, belongs to its users. My daughter, then a preteen, understood this instinctively. 

So often, we product managers, product designers, and product makers think primarily about our own relationship to the product. What should we build next? Can we fit this in the next release? Sales wants a feature: can we promise it? All of those questions put us, the team of people making the product, at the center. But that’s not where we belong. “Dad has an instagram” reminds us that the relationship between a product and its maker is only meaningful if we understand and prioritize the relationship between a product and its user.

The most powerful tool in your toolkit

The product and experience design community has developed many powerful tools and methods to help product managers, designers, and makers. At SDG, our product strategists use the Kano model, relative value, North Star Framework, theme-based roadmaps, and opportunity/solution mapping. We visualize these with grids, Venn diagrams, 4-blocks, 9-blocks, and swim lanes. Our user experience designers and researchers build user personas, craft journey maps, and make mockups, wireframes, and prototypes. 

But of all these tools and methods available to product teams, the most powerful is getting to know the people who use your product. The product — as my daughter observed — is theirs, even more than it’s yours. So spend time observing them, talking with them, listening to them. I’d get rid of every chart and model and software tool in my product kit before I’d get rid of time spent with users.

But of all these tools and methods available to product teams, the most powerful is getting to know the people who use your product.

How to get to know your users

Here are some tips to help you get to know your users.

1. Understand your users’ context.
Most software products are made in a similar physical environment, usually an office building with desks and coffee and decent lighting and nice double monitors (or, in these COVID times, in home offices). But much software is not used in such an environment. Users may be outdoors, under pressure, available only in brief bursts. Software used in, say, a pediatric dental office might be used with rubber gloves while a worried child weeps nearby. Software used in an industrial setting may have thunderous machines in the background and only be available between shifts. Pay attention to how they actually use the product, even if it’s not how you think they should be using it. You’ll learn a great deal if you Get Out of the Building into the wild, where your users are. Product folks have even developed an acronym for this behavior: GOOBing.

2. Understand your users’ stories.
Your users are engaging with your product for a reason: to help them with their work, to increase their understanding, to ease transactions, to improve their lives. You’ll make better choices and thus better products if you know their stories. For example, a medtech product might be used by people with a history of health concerns, who are feeling fear, uncertainty, and anxiety. You should respond to them differently than you would on a product used to help an eager bride and groom plan their wedding. Understanding the stories of people — needs and desires, frustrations and fears — will help you with priorities, user flow, layout, interface text, and navigation.

This understanding of users’ stories in order to understand needs and potential responses is where product management and product design converge. A marketer or business manager may get involved in product work to address business and market opportunities. An interaction designer may get involved in product work to tackle human factor and interaction challenges. But both are concerned with the story of the product’s users. This is why we believe that product designers and even playwrights and poets make great product managers, researchers, or analysts. Product work can learn much from disciplines like anthropology or even fine arts: don’t overlook such skills as you build your team.

3. Involve your whole team.
Empowered, cross-functional teams make the greatest products. But many product teams rely on one or two people to understand the users, while the bulk of the team simply takes direction from those emissaries. For example, it’s commonplace for a business to think that the designer on the team should handle user research on her own, and to worry that including developers in these activities is a waste of time and money.

I’ve found that everyone benefits from time spent with users. Engineers who witness the frustrations a user has with the product they’ve made will understand the issue more completely than one who is just responding to JIRA tickets. So include the whole team in the field trip to a user site, or at the very least organize a viewing party where the whole team can watch the recordings of research sessions. Rather than being an inefficient use of expensive developer time, it’s the quickest way to build empathy and understanding. It will pay for itself many times over.

I can honestly say that in my 25 years or so working on digital product, I’ve never had a single conversation with a user that felt like a waste of time. Every conversation, every observation is time well spent. So if you want to supercharge your product mindset, get up from your desk, shut down your laptop, and get out into the wild, where your users roam. 

Photo credits:
Conversation and coffee by Priscilla Du Preez on Unsplash
Engineer Photo by ThisisEngineering RAEng on Unsplash

The Product Mindset

The Product Mindset

Insight

The Product Mindset

Written by Jason Scherschligt
On December 17, 2020
Product is enjoying a moment. Twenty years ago, when I first landed a job with the title of “Product manager, interactive media,” not many people even knew what the job was. (Confession: I may not have even known what the job was!). Now every smart company is building up teams of product pros, and product manager was ranked 4th on Glassdoor’s recent list of 10 Best Jobs in America. The reason for the rise of product management is clear: product skills help companies satisfy customers, win markets, and build their business.

Consultants and bloggers (yeah, I’m both) have sprung up to help leaders and teams get better at “doing product.” We product folks often talk about “having a product orientation,” “becoming product-led,” or “adopting the product mindset” — but to do that, you first need to understand what a product even is.

Product, defined

Let’s start by defining product. I define it broadly:

A product is a response to a human need or desire that confers benefit to both the recipient and the provider of the response.

So if a company makes a thing that satisfies a person’s need, and the person is willing to do something that benefits the company, like give them money, well, that thing is a product. In some cases, the product is obvious. I need to open a can of soup, the Acme Can Opener Company makes a device that does just that, so I pay Acme for its can opener, its product.  The product is what connects Acme’s mission — “we shall leave no can unopened” — to their customers’ need — “I’d like some soup, but gosh darn it, it’s sealed up in this can.”

Software, including websites and mobile apps, complicates this a bit. In a world where every type of interaction, from banking to dating, is intermediated by software, human needs and desires are often best met by a digital experience — so those digital experiences are products too, just like the physical items are.

As a thought experiment, imagine other human needs that the Acme Can Opener Company might identify and respond to. 

Category User need or desire Response that meets that need or desire — in other words, product
Commerce “I need to buy a can opener.” E-commerce website
Service “I need to repair my can opener.” Customer support knowledgebase, repair services, scheduling tools
Business-to-business “I’m a can opener dealer. I need to maintain my inventory.” Portals and other systems for B2B users
Customization and configuration “I’d like to monogram my can opener.” Customization app integrated with manufacturing systems
Community “I’d enjoy meeting other can opening enthusiasts.” Forums, personal profiles, messaging, networking tools

All of the systems and experiences that address these needs, solve these problems, or satisfy these desires are products, as much as the can opener itself is. And they require vision, planning, execution, and sustenance: all of it is product work, done by product managers and product teams.

In a world where every type of interaction is intermediated by software, human needs and desires are often met by a digital experience — so those digital experiences are products too, just like the physical items are.

Product as a mindset

Once we understand product, it’s easier to understand the product mindset. It’s an organization’s behaviors and structures that are oriented towards making, delivering, and supporting great products — which again, are responses to the needs of humans.

Here’s an list of some of the most important of these behaviors and structures.

  • A near obsession with understanding the people who use your products
  • Empathetically listening to and observing the behaviors and needs of customers​
  • Relentlessly delivering value​
  • Celebrating impact over celebrating output
  • Designing to solve problems​, not just as decoration
  • Accountabity to business goals​, even more than project plans
  • Organizing in cross-functional, relatively autonomous teams
  • Embracing, rather than resisting, change​

This mindset can supercharge business success. When you and your team adopt a product mindset, your priorities become clearer. Your organization understands its customers. You become more observant. You become more innovative. You become more aligned as a team. People become more satisfied. 

Building this product mindset isn’t easy — what is? — but it’s the hallmark of many great products and teams. Do this, and the world will be your oyster. Oh, and those oysters come in a can.

Can Opener The Product Mindset

Photo credits:

Rock cairn photo by Sean Stratton on Unsplash
Tablet photo by Leon Seibert on Unsplash