Blockchain 101: Real-World Uses

Blockchain 101: Real-World Uses

Blockchain 101: Real-World Uses

Written by Sean Kelley-Pegg
On

You might know Bitcoin as the preferred payment system for ransomware. Or as a volatile investment vehicle (which Warren Buffett won’t touch). You may have read about it as a virtual currency for money laundering or running pyramid schemes. Of course, it’s all those things, but like most things in technology there are two sides to the coin. Focusing on the extreme cases ignores some of the most exciting parts of crypto (for me at least) – the underlying blockchain technology. Blockchain has the potential to impact not just financial but also social systems, and as a technology professional it is important to understand what blockchain is with as little jargon as possible. Crypto land is annoyingly full of acronyms, memes and made-up words, so I hope to give a brief, high-altitude view of the landscape without a lot of clutter. 

 

So, what is blockchain and why is it important?

A blockchain is a way to share information in such a way that it cannot be changed or deleted. It does this by sharing the data among thousands of participating computers which come to a consensus on “blocks” of new transactions. Anyone can participate by running blockchain software and people doing so are located all over the world. Entities are motivated to not disrupt the system because they can earn money automatically by participating in a well-running system. The decentralized nature of blockchain combined with rewards of participating make it a “highly available” system with powerful hedges against being shut down or fraudulent data being saved into blocks.  

Imagine a spreadsheet of transactions that can have rows added but not modified. The spreadsheet is shared globally and can be read by anyone. Each time a transaction occurs a new row is added recording who sent how much to whom. Because rows cannot be changed there can be no disputes about whether transactions occurred and no possibility of changing information later. Since this spreadsheet records interactions automatically, people can transact directly with each other without involving an institution like a bank, and without needing to know or even trust each other. Like Venmo but without the settlement delays.  

In 2009 Bitcoin was created demonstrating the viability of this concept. However, the real-world uses of Bitcoin were limited. At the time it was difficult to trade dollars for Bitcoin and you couldn’t really buy much with it, except on the black market. Some of the original developers saw promise in the concept and started work on a new blockchain with wider use cases called Ethereum.  

The Ethereum blockchain can store just about any other data along with the transaction. This unlocks many possibilities. For example, ownership of property could be recorded on the blockchain, reducing the need for titles or deeds or other physical documents. Blockchain could store identity information which could be used to reduce online fraud. Forget hacking usernames & passwords –you can’t steal someone’s identity if you don’t have their crypto “keys!” Products could be tracked throughout the supply chain and verified by the manufacturer or purchaser –think organics, temperature-sensitive medications, or how certain raw materials are sourced. A blockchain-integrated voting system could prevent vote tampering. Votes would be permanently recorded, and because the blockchain is public, it would be easier and faster to audit a close election. This in turn could increase confidence in the vote.  

Another Ethereum concept is the “smart contract,” a piece of custom programming that executes along with the transaction to which all parties have agreed. Smart contracts are often compared to vending machines -we put in our money and receive our selection, and the process is completely automated. Smart contracts can be used to initiate any kind of workflow we can think of. For example, escrow money could be released when conditions have been met. Tickets could be issued or traded or automatically refunded in certain cases. A smart contract could be tied to the purchase of digital art so that whenever the work is re-sold a royalty is automatically paid to the original artist. Programmable money!  

Blockchains in businesses

Many large companies are already exploring how their own private blockchains can reduce friction, speed transactions, and increase trust and transparency. IBM has many different implementations of their blockchain for supply chain customers and for those who manage digital assets. Visa is reportedly exploring how the technology could speed up international transactions. Pfizer, Biogen, and other major pharmaceutical companies have formed the Clinical Supply Blockchain Working Group to develop blockchain solutions specific to their market. The Linux Foundation runs Hyperledger Fabric, a framework for building blockchain solutions, and of course Amazon AWS offers a managed blockchain service.  

Those projects often use more centralized corporate blockchains, but there is also a vast network of interesting projects backed by the open-source Ethereum blockchain. I’m excited about IPFS (“Interplanetary File System”), a decentralized way to store encrypted files on the blockchain, making them always available (or one might say censorship-resistant). Another interesting project is “Gitcoin Grants” which uses decentralized voting to distribute crowdsourced funding for blockchain projects. Many of their grants aspire to contribute to the “public good” in some way and support the ideals of shared ownership and collective determination rather than simply making money.  

Benefits of blockchain

The concept of “public good” runs deep in the Ethereum community and many projects display a fresh idealism about creating systems that are fair, do not discriminate, and hedge against some of the more harmful effects of global capitalism.  

For example, blockchain-based voting enables people to organize across national boundaries for a cause they all believe in. Organizations like this are known as Decentralized Autonomous Organizations, or “DAOs,” facilitate human organization at a global scale without needing governments to approve.

Streaming music projects like Audius, Stream.xyz and Catalog aim to compete with platforms such as Spotify, while using blockchain automation to put control back in the hands of the artist. The projects aim to connect artists directly with their fans without going through a centralized gatekeeper. In contrast to the tiny royalties paid by the big streaming providers, these projects could enable fans to directly support their favorite artists and enable artists to create unique “editions” of their music with other digital content, increasing engagement.   

Blockchain-based currency can also benefit ordinary people living in volatile economies with runaway inflation. Strange to think of cryptocurrency as a hedge against risk! But in Venezuela, some supermarkets and food chains such as Pizza Hut reportedly accept cryptocurrency as payment, and it’s not unusual for small businesses to periodically convert Bolivars into crypto due to how fast that currency can fluctuate.  

Regardless, today there is at least one small way you can benefit from blockchain now, for free and without risk. On the web these days it seems like the price of admission is to put up with online tracking and ads that follow you throughout your day. We accept that we give away access to our browsing behavior in exchange for free access to sites and services. However, there is another option. The Brave browser blocks online tracking and ads by default, then gives you the option to opt into a discreet ad display in a separate tab. There is no requirement to opt in, but if you do, you earn their blockchain-backed “basic attention token (BAT)”. This is a bit like frequent-flyer points that can be used to tip website creators or be exchanged for gift cards or even Ethereum itself. The Brave browser advertising model flips the current Web 2 model on its head –you are the owner of your data, and you choose when to share it, and can expect compensation for it. 

So, thanks for coming on a flyover tour of blockchain, a technology that will impact all of us in some way in the coming years whether we work in technology or not. Forget about the price and focus on the promise. 

How to be sure your product can go the extra mile

How to be sure your product can go the extra mile

How to be sure your product can go the extra mile

Written by Jared Johnson
On

I am a product design strategist by trade, but a recreational runner on the side. Lately, I’ve realized that from intentional planning & preparation for a product launch to considering what direction you’re heading for a jog, there are many parallels between delivering digital products and going for a run. Here are a few things to guide your product team along the path of kicking-off a new product, collaborating continuously, and learning from where you’ve been to inform where you go next.  

 

Preparation is key

Before starting a run, I always spend time preparing my body and mind with stretches and warm-ups. Similarly before you start building a product you take time to prepare.

  • Setting up team working agreements are helpful in aligning how your team members will work together. Same goes with the business partners you collaborate with. Identifying what your organization cares about and circulating that information amongst your team will help keep the team heading in the right direction while executing daily tasks. Using tools like the North Star framework can help with this.  

  • When going out for a jog or building a product, you need to identify the why behind that decision. If an organization is simply looking to make money on a product chances are they won’t stand out from the market competition—or at least not for long. Intentionally thinking about why an organization cares about this product – why it’s worth the time, effort, and energy to create it, and why it matters to those it will serve – will aide in finding valuable motivation that is worth documenting to look back on when the going gets hard. 
  • Asking these types of questions begin to frame-up some other user-centered artifacts and documentation that can help collect feedback and build empathy for those who will be using the product or service once it’s launched. Creating items like an Empathy Map, Customer Journey/Experience Map, or a Service Blueprint can identify ways user needs (wants, feelings, path to completion, etc) overlap with how the business shows-up and can meet that why for the audience the product is intended to serve. 

  • In “The Product Mindset” blog series, Jason Scherschligt—Product Coach and fellow SDG consultant—maintains that getting to know users directly is always time well spent. The more we learn about their known and unknown needs, physical or logistical wants, pain points with other parts of the business, or their own process workflows, the more we’re able to build a product on their behalf. By sheer exposure to this information on a consistent basis, we are able to better retain and understand user needs than any acceptance criteria on a JIRA or Azure ticket could ever deliver in and of itself.

Success isn’t how far you go, but the distance you traveled from where you started.

Steve Prefontaine, American long-distance runner

Roll with the punches

Recently I had the pleasure of running a team race that covered a couple hundred miles of terrain. Although we planned and prepared as individuals, we also came together as a team to agree on how we would work together to cover the miles set before us. During the actual event, rain came, winds blew (so did tires on our pace vehicle), but we worked as a team to accomplish far more than we could as individuals.  

 

Similarly, when building a digital product or solution, things invariably change. Whether it’s a collective understanding of our users, the priorities of the business unit funding the product, or simply timeline changes outside of the team’s control, there will inevitably be changes the team will need to adapt to and overcome. To deliver a quality product on-time that is within-budget and meets the needs of its users, communication and clarity is crucial between the business itself, experts of the technology, and the end-users. Having collaborative mechanisms for capturing and sharing insights and prioritized problems to-be solved is critical for the delivery team to know not only where they are headed but how to get there. 

As an experience design consultant, I can support this process of documenting user needs, creating resources that help translate abstract ideas into visual or digital experiences, as well as working in tandem with the rest of the product and delivery team—and their leadership. Just like that team race, when we are aligned on the direction we are headed in, know the incremental steps to get there, and lean into our individual expertise & knowledge, we are able to go further faster than if we went it alone.

Champion the wins

When we finish our individual runs or larger team events—like that team race—it’s helpful to think and reflect on how things went. 

        • What decisions did we make that got us here?  
        • How could we do things differently? 
        • Where could we improve next time? 

Similarly, traditional Agile ceremonies like Retrospectives (to assess how the team worked together during the last Sprint) and Reviews (to show & tell what was delivered the previous Sprint) are helpful ways to look backward to help inform what to do next. Finding ways of assessing performance, identifying success (as your team defines it), and celebrating achievements is essential in the process of creating new products and solutions.  

I have learned a lot about myself as a recreational runner, but I was able to cover more ground and grow more as a person anytime I have run as part of a team. Whether you are a team leader, individual contributor, or somewhere in between, I hope you’re able to support the product you’re building with some intentional preparation, rolling with the punches, and championing the wins as they come. That’s how you can be sure your product can go the extra mile.  

The Product Mindset: Promises, Promises

The Product Mindset: Promises, Promises

The Product Mindset: Promises, Promises

Written by Jason Scherschligt
On

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

“I understand agile is about accounting for uncertainty by breaking work into small chunks and releasing product as things are completed,” said the CEO. “But as we work with customers, our business needs to deal with dates and dollars, not story points and sprints.” And then came the kicker: “We can’t operate a business if we can’t make and keep any commitments.”

These were the words of a talented CEO of an innovative growth-stage B2B technology firm I’ve worked with, reflecting a very real concern of business leaders. This CEO and his colleagues work with major multinational customers, and the nature of their business involves long business cycles with dramatic seasonal effects — in an industry where certain functionality needs to be available at a certain time of year or you might as well wait another year to deliver it. They sell many months or even years in advance, and their customers are making significant buying decisions based on expectations of functionality they’d like available in the future.

This CEO and his leadership team were interested in strengthening their product management and discovery approaches and agile development methods, and they understood that learning and adapting were essential to delivering great products. I’d been consulting with them for a few months, helping them employ foundational principles of agile product development and value-driven product management. Over those few months I’d worked with them to declare a strategic product vision, reframe product roadmaps from lists of features to opportunities to deliver value, conduct user research with some of my research colleagues from SDG, and re-organize their product development teams. We’d even had a little book club-style discussion on Melissa Perri’s excellent book Escaping the Build Trap. It was a productive and successful engagement, but we got tripped up when we worked on removing some specific features from future time horizons.

“Let’s not commit to these features yet,” I advised. “There may be higher priority problems. Beware of the build trap, remember.”

But in this case, the CEO and his sales leaders resisted. They couldn’t just tell major customers that they didn’t yet know if and when they would deliver these high-profile features, the CEO explained.

And he was right.

High-Integrity Commitments

This CEO’s business isn’t unique. Many companies want to adopt processes (agility, leanness) that enable them to respond more nimbly to market needs but they also need to be able to set expectations and keep the promises they make to the market. Otherwise, they may lose valued customers and struggle to win new ones.

Product guru Marty Cagan, of the Silicon Valley Product Group, uses the lovely phrase “high-integrity commitments” to refer to the expectations that businesses must establish and keep. Cagan deftly describes the situation like this:

“There are always certain cases where we need the team to make what is called a high-integrity commitment…In all businesses there are occasional situations where something important must be delivered by a specific deadline date…So a key condition to moving to empowered teams is that the teams are able to provide dates and deliverables when necessary, and further, not just the low-integrity dates of the roadmap era (because we really had very little understanding of what was being committed to), but dates the leaders can count on.”

Source: Silicon Valley Product Group, https://svpg.com/team-objectives-commitments/

Here Cagan recognizes that commitments to dates and deliverables may be critical to producing a successful product and operating a successful business. Some product purists might resist this ethos after all, aren’t we trying to deliver value, not hit dates? but the reality is inescapable: businesses can rarely survive without being able to tell customers about functionality to come, especially in B2B, enterprise software. And that requires even the most agile, adaptable product team to make and keep — commitments.

“The reality is inescapable: businesses can rarely survive without being able to tell customers about functionality to come, especially in B2B, enterprise software. And that requires even the most agile, adaptable product team to make — and keep — commitment.”

 

Keys to Commitments

How can product teams improve at making and keeping these high-integrity commitments, while retaining flexibility necessary to discover and deliver a high-quality product? Here are some keys.

1. Feature commitments should be rare and precious

While yes, we sometimes do need to commit to a feature by a date, I must be clear: make these commitments only when they’re truly warranted to build the business and win your market. Most of your product planning and development should be focused on uncovering value and adapting as you learn. Commitments to features by dates should be rare and precious.

2. Build trusting, communicative relationships with colleagues in other parts of the business

This sounds squishy, but it’s a foundation of product commitments. Sales and product teams will be more comfortable making high-integrity commitments if they trust each other and assume they each mean well.

Sales, hear this: product makers (engineering, UX, research) don’t want to derail a business or discourage sales; they just don’t want to commit to making something that isn’t yet understood. Before you make a commitment to a customer, confirm with Product that this commitment can be met, and seek to understand what other work might be sacrificed to meet it.

And Product teams, hear this: Sales or Marketing doesn’t want to put product makers in an impossible situation; they just want to be able to go to market with some confidence that what they’re selling is what will be shipped. When you share a roadmap with your Sales brethren, clarify what’s relatively certain, and identify what’s less clear. Otherwise, Sales may presume either that all of it is set in stone, or that all of it is equally uncertain.

An attitude of trust, team alignment, and safety is essential to building a good team. If your team doesn’t have this foundation of trust and positive intent, we suggest simple exercises where teams list what we believe to be true about our coworkers and use these to surface biases, beliefs, and concerns.

 3. Separate product discovery from development

To make and keep commitments with confidence, many teams find it helpful to separate product discovery work (“what should we deliver”) from delivery work (“how should we deliver it?”). There are many models and frameworks for this, like Double-Diamond models, or Dual-track processes. Depending on your team, your maturity, and your business, some may be better suited for you than others. But no matter what method you select, adequate space for discovery enables product teams to explore options and uncover solutions that can help them make commitments. Instead of demanding that product teams declare whether they can meet a commitment to functionality immediately, the savvy sales team will give that product team time to do enough discovery work. After all, that discovery work is what enables the product team to understand the problem and opportunity enough to make a commitment.

4. Reframe priorities and commitments to focus on problems you’ll solve, not features you’ll ship

Customers rarely want a feature; they want their needs satisfied or their problems solved. So if possible rather than committing to a feature, commit to tackling a problem. This is still a commitment, but you’ll have more flexibility to deliver a strong solution, rather than the solution your customer prescribed. Your product will be stronger because of it. 

Product leaders even good, caring ones ⁠— can be tempted to retreat to the immaculate realm of product in theory, where design and discovery are showered with love and budget, while sales and revenue are the dirty concerns of the mercenaries in the bizdev and sales departments. Resist this temptation. A product only exists in the messy space between your business and your customers. That business is built by sweat and toil, and it requires those customers to spend their money. So sales commitments are among the most important conversations your business has with its customers. The smart product leader recognizes this; the smarter product leader embraces this.

Featured image by Hunter Newman on Unsplash

Your “product” driver has arrived

Your “product” driver has arrived

Your “product” driver has arrived

Written by Brian Ganas
On

Being assigned as a Product Owner feels a little bit like being handed the keys to a brand new car only to watch your driving instructor get in after you and immediately ask if you remember how to activate the defroster. The excitement and adrenaline you feel knowing you’ve been handed a position of authority is somewhat dashed as soon as you realize you’re not really in control — not really.

Product Owners, based on the guidelines of Scrum, are to be trusted with full autonomy and exclusive decision-making regarding the product they are in charge of. But it becomes very clear in reality that Product Owners are bound to many of the same limitations we all face in life — there is usually someone giving us direction that we need to follow. Executives, clients, users, all sorts of parties play a role in dictating what goes into a product — their wants, needs, and directives are usually not easily dismissed in cases of disagreement.

Becoming the Driver

Based on my own experiences, I shifted my mentality about being a Product Owner. Here’s how I view it. Yes, I hold the keys to the car. I control my speed, my lane changes, my negotiation with traffic, etc. I am in full control of that vehicle. But rather than driving wherever I and only I want to go, instead I think of myself more like a rideshare driver. I’ve picked up a passenger who has given me a destination, along with a few other directives — spoken and unspoken. My job as the driver, or as the Product Owner, is to deliver my passenger to their destination while meeting other expectations they’ve laid out for me. BUT, I am still in control.

I will have to use practical knowledge to drive the app to the destination, identifying roadblocks and the most efficient routes I can use to get there. I will need to identify and follow detours when they come up. I will have to follow local regulations to ensure I am not violating laws.

I will have to use my softer skills to identify the type of journey my customer wants from me. Do they want frequent, verbal updates on our progress? Do they want to sit in silence and only raise an objection when something appears to deviate from their expectations? Do they want to handle me like a partner or a vendor of a service who is paid to do what they say? Do they want to stop at Taco Bell on the way? All of these questions require answers, though I am not always able to have my customer directly answer them for me. I have to infer and identify those answers myself.

As Product Owners, we remain in the driver’s seat, but we need to remember we’re here to provide a service for someone else. We’re trusted to deliver the product, to bring us to our destination, but we may need to explain our process or justify the decisions we make. When we make a turn the customer wasn’t expecting, or take a different route than they’re used to, we have to utilize our expertise and explain why this is the right decision. We need to be open to customer feedback; they may know things we don’t know.

Being a Product Owner should be viewed as a partnership as much as the service rideshare drivers offer us. There is no explicit right or wrong way to conduct the work, but there are rules that have to be followed and courtesies that have to be extended. Product Owners are in control but we must never forget that we are here to service our customers. They rely on us, on our expertise, and our guidance to get them the solution they need. We rely on them to give us useful direction, fill in gaps in our knowledge, and help us deliver an exceptional customer service experience. We should always remember the significance and the importance of that partnership.

Hold the keys to the car with pride, Product Owner. Let’s get our customers home safely.

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

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

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.