From Atoms to Pixels: Digital Product and Manufacturing

From Atoms to Pixels: Digital Product and Manufacturing

From Atoms to Pixels: Digital Product and Manufacturing

Written by
On June 16, 2021

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

At first glance, software companies and manufacturing companies seem diametrically opposed: pixels vs atoms, machine learning vs. machines, bits and bytes vs. nuts and bolts.

Modern product management nerds like me spend a lot of time with companies and teams whose primary output is digital, comprising data and experiences that use computing technology and software engineering techniques to enable users to interact through websites, installed software, or mobile apps. It’s a discipline combining the best parts of user experience design, marketing, business strategy, and software development and delivery.

Meanwhile, manufacturers of physical products are engaged in their own professional domains — and, by the way, manufacturing contributes about 2.3 trillion dollars to the US GDP each year. These businesses have deep expertise in materials, chemistry, physics, manufacturability, supply chains, operations, safety, and logistics, things many digital product companies aren’t particularly concerned with. At first glance, these manufacturers might not seem too concerned with the processes of UX design and agile software development

But that’s at first glance.

A False Binary

Take another look, and you realize that this binary division between software and manufacturing companies, like so many binary divisions (IT vs. the business, STEM vs. the humanities, rock n’ roll vs. country) is false. It obscures and limits rather than clarifies and enhances. 

The truth is the modern manufacturing company is, in many cases, an honest to goodness software company too, just as much as the hottest consumer internet brand. These manufacturing companies use software throughout their businesses, both for internal operations and for interacting with customers through marketing, commerce, service, configuration, and distribution.

The archetypical lifecycle of such a company looks like this. They started many years ago, became successful at building and selling physical products in a specific market (dog food, brake pads, microwave ovens), and perhaps expanded into adjacent markets. At some point, perhaps in the 1970s or 80s, they started using software internally to manage operations and facilitate decision making. Finally, perhaps relatively recently, they turned that software outward, using the Web and mobile apps to satisfy and delight customers. And so now, they are both a manufacturing company and a software company even if in some cases, they don’t even realize it. This is what Marc Andreesen meant when he said, famously, “software is eating the world.” 

Here’s an example: A few years ago, I led digital product and UX for a venerable provider of yearbooks, class rings, and other manufactured products for celebrating scholastic achievements. That company has outstanding manufacturing facilities and processes. They operate huge plants where they print millions upon millions of yearbook pages. At other facilities they use sophisticated custom engineering and precision manufacturing to make one-of-a-kind pieces of commemorative jewelry.

But we also designed and built some interesting and impressive digital experiences that were part of the product experience. High school yearbook editors, designers, and photographers used our custom-built web-based publishing tools and mobile apps to collect memories of a school year and to design great pages and book covers. That one-of-a-kind ring that commemorates a student’s school experience or championship crown? It was designed through an app, rendered in 3D, purchased through e-commerce and shared on social media before it ever became a physical object. And that software is a product provided by this company as much as the ring itself is. 

So is that company a manufacturing company? Yes, absolutely.

Is it a software company? Yes, absolutely.

The truth is the modern manufacturing company is, in many cases, an honest to goodness software company too, just as much as the hottest consumer internet brand.

Tips for manufacturers adopting a digital product mindset

Because a manufacturing company is a software company, too, it stands to reason that the manufacturing company that wants to differentiate can do so by strengthening its digital product capabilities. If you’re a manufacturer interested in adopting the techniques, teams, and processes of consumer Web-based technology, consider the following:

  • Start with the story of your customers. Think creatively and expansively about their needs. Then, focus on meeting their needs through a combination of digital and physical interventions. Say you manufacture dog food. Dog food customers don’t just need tasty kibble to fill their pooches’ bowls; they need to care for their dogs’ nutritional needs. You, a dog food maker, might find opportunities to win new customers and surpass your competition if you can uncover software-enabled ways to address these needs. In addition to providing food, can you also help with feeding schedules, hunger alerts (app name: Pavlov!), delivery of heavy bags, analysis of pet health?
  • Introduce your manufacturing and software teams to each other. One easy tip: make sure your software teams and your manufacturing teams get to know each other. They’ll learn a lot from each other, and both teams’ work will improve. In addition to getting out of the building (“GOOBing”) to spend time with customers, your software product teams should pay a visit to your manufacturing facilities, too. 
  • Focus on iterative discovery before concerning yourself with efficiency and scale. Manufacturing operations pros are excellent at designing processes to efficiently produce high-quality goods at scale. But if you are developing digital products, you should experiment and validate (and possibly disregard or change course) before you try to scale up a new product or process. Steve Blank, a software startup guru, says that the greatest risk to a tech business is premature scaling. That’s true for manufacturing companies developing their software product expertise, too. Instead, squeeze out inefficiencies after you’ve achieved product-market fit.
  • Understand where software and physical products differ. One example: in software, a small but meaningful error in text can be repaired with just a few keystrokes and a push to production. But if that same error is included in, say, printed packaging, the cost of correcting it after the fact can be substantial. Investment in QA processes could therefore vary widely between software and manufacturing teams. Other areas where manufacturing models and software models differ significantly: mass customization, globalization, distribution, and upgrades and improvements.
  • Consider new business models. Could a lawnmower company include subscriptions to insights about grass cutting? Could a birdfeeder-maker pair with advertising driven content about our feathered friends? Subscriptions, advertising, upsells, personalization, premium memberships, e-learning: these are just some of the core models of technology product firms. They could apply to you, too.
  • Hire and organize staff with the specialized skillsets of software products. As they build their software product capabilities, manufacturers may need user experience designers, data scientists, software developers, content writers and producers, and digital product managers. Depending on your organizational dynamics, consider separating your digital product function from the IT function, to give your digital product leaders their own seat at the leadership table. Or think of it this way: Google has a world-class IT department, but its IT department doesn’t build Google’s software products (search, maps, docs, etc.) Similarly, in many cases a manufacturer’s software products may be best handled by a dedicated product function outside the IT department. 
  • Manage your digital initiatives with product measurements. You may be inclined to think that your physical goods are your products, while the digital stuff is another IT project, much like your ERP upgrade or the new email server. These projects’ success is typically measured by delivery dates, resources, and budgets. These are important, but they’re internal metrics. Your product makers and leaders need to be concerned with business metrics: customer acquisition, retention, satisfaction, competitive differentiation.
  • Adopt a product mindset for your software. With our customers, we use the term product mindset as our shorthand for the set of attitudes, beliefs, tools, and processes that produce great products. The essential elements of this mindset: Listen to your users. Delight through experience. Deliver often, even relentlessly. Shift requirements as you learn more. Adapt and learn, rather than gate and stage. Recognize that while successful projects end, successful products endure. 

Manufacturers aren’t going anywhere. As long as humans live in a world where physical goods contribute to our comfort, well-being, mobility, and economic viability, we’ll always use and appreciate things that are made. But the line between the virtual and the physical, the pixels and the atoms is getting blurrier every day. If you’re a manufacturing company, remember that you’re probably also a software company. So you might as well start acting like one.

Image Credits:

Industrial Drill photo by Greg Rosenke on Unsplash
Women working in manufacturing facility photo by Remy Gieling on Unsplash
Wind Turbine plant photo by Science in HD on Unsplash

 

Hybrid Cloud: “the best of both worlds”

Hybrid Cloud: “the best of both worlds”

Hybrid Cloud: “the best of both worlds”

Written by
On April 22, 2021

Cloud delivered

The cloud has successfully delivered on its promise to bring highly-scalable, resilient applications with seamless deployment while reducing infrastructure cost. This change has also assisted in more agile development with a better focus on return on investment across projects. Unfortunately, that opportunity has been out of reach for many organizations for many different reasons, from regulations and contractual requirements to seasonality timing that make the process take too long.

The best of both worlds

The Hybrid Cloud offers a “best of both worlds” environment: companies can now embrace the cloud for speed and scalability where feasible while also maintaining their existing infrastructure. This allows organizations to lean on the cloud for things like emergency scaling, rapid development, testing environments, and production workloads that may not require their bespoke infrastructure while maximizing their returns on that internal hardware by ensuring that it is focused on value-add workloads.

Azure has released a key set of tooling that will enable the transition to a Hybrid Cloud by allowing companies to embrace a cloud-native application development strategy internally while still letting the operations teams focus on managing the environments from a single point of management. In addition, application lifecycles can shift between cloud and on-premises environments with relative ease without requiring development efforts.

Microsoft offers both an all-inclusive solution for Hybrid Clouds as well as an ala carte approach that allows you to slowly transition from a fully on-premises environment to a hybrid environment.

Looking for turn key

For an all-inclusive, turn-key Hybrid Cloud migration strategy, Microsoft offers a suite of services under the Azure Stack umbrella. Targeted toward larger enterprises and higher velocity migrations, Azure Stack is a foundational transformation that will have an organization in a fully functional Hybrid Cloud environment with application delivery combined with full monitoring and environment management.

Establishing a foothold in the Hybrid Cloud environment can sometimes have time, go-to-market, or compliance management challenges that could necessitate an aggressive timeline. The Azure Stack solution provides the ability for an organization to achieve their Hybrid Cloud goals more quickly by offsetting time costs with increased investment on the front-end.

What’s new

Their newer products also offer a gradual transition, offering the ability for organizations to design and develop their products going forward with a cloud-native mindset to the extent that makes sense while taking advantage of the monitoring and management capabilities right away. This is achieved through the Azure Arc and Azure ExpressRoute products.

Azure Arc provides a platform to manage a wide variety of resources and centralize security and management processes to a single portal. With the ability to manage both Windows and Linux environments as well as tap into Kubernetes, this provides the single point of management that is critical to successfully running a hybrid cloud environment.

By letting teams develop and manage processes across the organization, both for cloud and on-prem environments, without having to work through complex rollout pipelines and delivery complications, the complexities of running both on-premises and cloud-hosted resources becomes a more achievable task.

In addition, teams can enhance existing cloud-based scaling capabilities by leveraging its automated Machine Learning based scaling capabilities at a service delivery level.

Hit the ExpressRoute

Azure ExpressRoute is Microsoft’s private VPN offering that allows a direct link between on-premises data centers and Azure hosted environments.

For organizations that ship substantial amounts of data this can be a saving grace as data fees are more like a traditional ISP fee structure based on bandwidth requirements with on-demand offerings. In addition, because the ExpressRoute connectivity is provided by a traditional service provider there is opportunity to shop around to save on cost or consolidate to a single bill.

For application developers, ExpressRoute is a seamless interconnection between the two environments, which will speed up development, reduce maintenance costs, and eliminate complicated firewall and VPN configuration.

If you’re still not ready to go all in on a cloud solution for your business, the hybrid cloud is one way to get the ball rolling in your cloud journey while you stay focused on value-add workloads. When leveraging the cloud for higher scalability and lower infrastructure costs, one size doesn’t fit all, but there are definitely more options for consideration now- that make the hybrid cloud a great approach.

The Product Mindset: Let Them Eat Cake

The Product Mindset: Let Them Eat Cake

The Product Mindset: Let Them Eat Cake

Written by
On April 8, 2021
For a clue about what a company or team (or a person or nation) values, just look at what it celebrates. After all, we celebrate things we’re proud of or things that are meaningful to us.

If you work in business or technology, you’re likely familiar with the rituals of celebrations in a workplace: donuts in the breakroom, a leader’s words of commendation, some small talk and standing around. In fact, the popular TV show The Office had a long-running gag about employees maneuvering for control of the Scranton branch’s influential Party Planning Committee. That joke wouldn’t have worked if we didn’t understand office celebrations.

While our time in offices has been sorely limited in recent months (Thanks, COVID!), think back to those workplace celebrations. What events do you celebrate in the office? Probably personnel moves like new hires, departures, and promotions, yes. Maybe a few personal events, like baby showers or significant birthdays.

But I’m guessing your workplace also celebrates major achievements in projects. The upgrade was finished, you shipped the release, the milestone was reached. So someone brought in a big box of bagels or picked up artisnal donuts at a hipster bakery. Maybe you all took off early and enjoyed a happy hour at a local tavern. Project managers and teams are well-conditioned to celebrate these project milestones. “Let’s all have cake in the break room!” “Why?” “Because the thing we were doing is done!”

Don’t just celebrate project achievements

Now, I’m not here to denigrate donuts, taverns, or cake. (Although, watch the carbs, people!) And celebrating achievements can certainly help a team’s motivation and cohesion. But when you celebrate the tasks you’ve completed or dates you’ve hit, you’re ignoring the real indicators of product excellence: user needs you’ve met, markets you’ve expanded, things you’ve learned, success you’ve built. A cake to honor a thing finished on time and on budget is a ritual of a project.
Projects are a great way to organize resources or manage and sequence labor. I’ve known many wonderful project managers and benefitted from great project tools and resources.  But a project’s primary concern is inward: deliverables, schedule, budget. Customers don’t really care about the way we organize resources or manage and sequence labor. Our work breakdown structure is of little concern to the user. They are not delighted when your actuals matched your estimates. In too many cases, customers don’t even care about your project’s requirements, a nominee for the strangest word in tech.
The uncomfortable truth: that artisnal donut with the real maple frosting might just be celebrating the wrong thing done well. So I prefer celebrating product successes. A product mindset, or a product orientation, looks differently at work worthy of celebration. While projects are a way of organizing labor & resources, product is primarily concerned with delivering meaningful responses to satisfy the needs of your users, and therefore with generating value that endures. And so teams with a product mindset celebrate progress towards that value.
The uncomfortable truth: that artisnal donut with the real maple frosting might just be celebrating the wrong thing done well.

Celebrating product success

With that in mind, try adding new rituals to your workplace celebrations. Here are some other things a product team might commemorate:

  • Something you learned. If you’ve uncovered meaningful new information about a market, or even learned something about your teammates that will help you work together, you’ve made progress towards a valuable product. That’s worth celebrating.
  • A change in your requirements or plans. This may sound crazy to project leaders, but a changed requirement usually means you know more about what your customer wants. And that’s worth celebrating.
  • New insights from customers. Did you visit a customer site? Did you bring users in and get their insights on your prototype? If so, you’ve likely learned something about your value hypothesis. And that’s worth celebrating.
  • A customer outcome. This is a big one. If your product solved a problem for a cohort of customers or improved the value exchanged between your business and your users, then the product is performing its essential role as a vehicle of value. And that’s worth celebrating.
  • Business milestones traced to product work. If you’ve crossed a threshold in customer satisfaction (“First month ever with more customers using the self-service online product than called the tech support hotline”) or sales and revenue (“Over $10 million in the product’s subscription sales in Q3”), and you can see how your product drove that achievement, well, that’s worth celebrating.

So yes, happy hours and cake in the breakroom are great little rituals of our professional lives. And donuts are undeniably delicious. But the next time you’re planning a team-building celebration, ask yourself, “Are we celebrating mere output, or meaningful outcomes?”  

Sparkling Cupcakes for a work celebration

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

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 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/