When an organization shifts from delivery or feature teams to product teams, the first step is often a change to team structure.

Delivery and feature teams are often structured by function—front-end teams, back-end teams, mobile teams, etc. These teams can rarely deliver value on their own. Instead, they hand off work from team to team—the back-end engineers design the data model and system architecture, the front-end engineers build the interface elements, the mobile engineers work toward feature parity, etc.

The challenge with this way of working is that it is both slow and constraining. It’s easy for a back-end team to make decisions that limit what’s possible in the front-end. Feature parity across desktop and mobile is rarely what customers need or want.

If an organization wants to shift to product teams—teams empowered to drive outcomes—they need to structure their teams such that each team includes the necessary skills and abilities required to build and deliver customer value. This type of team might include a back-end engineer, a front-end engineer, a mobile engineer, and/or any number of full-stack engineers.

If an organization wants to shift to product teams (empowered to drive outcomes) they need to structure them so each team includes the necessary skills and abilities required to build and deliver customer value. – Tweet This

So what happens when you want to make the switch from one type of team to the other?

This was a question that recently came up in the Continuous Discovery Habits community, where one member was wondering about how to make this transition as smoothly as possible.

For this post, we’ll share both advice from the community as well as Teresa’s suggestions on how to best handle this situation.

Question: What advice do you have for companies moving from functional teams to value-driven, cross-functional squads?

This question came from Joel Beverley, Co-founder at RotaCloud, who explained that his company is looking to restructure from platform teams (e.g. back-end, web front-end, and mobile front-end) to squads. Joel turned to the community to see if anyone had any tips or advice on introducing these changes or any pitfalls to watch out for.

Sam Lightowler’s Advice: Use a Diagram to Demonstrate Value

Meet Sam Lightowler, Senior Manager of OTT Operations at Canadian Broadcasting Corporation.

Sam Lightowler, Senior Manager of OTT Operations at Canadian Broadcasting Corporation (CBC) stepped in to share her experience.

A little background on Sam and her organization: Sam oversees the four product teams that manage two streaming services, ICI TOU.TV and CBC Gem. These were previously two completely separate sets of products managed by separate French and English arms of the organization.

• Empowered product teams that own their outcomes, can measure the value they are delivering, and can autonomously deliver features with minimal dependencies and coordination with other teams.
• Having product teams become subject matter experts on audience patterns and behavior as it pertains to their portion of the overall product/user experience.
• Maintaining feature parity across as many of their platforms as possible.

We wanted empowered product teams that own their outcomes, can measure the value they are delivering, and can autonomously deliver features with minimal dependencies and coordination with other teams. – Tweet This

Sam says this transition at CBC involved about 50 people being reorganized into cross-functional product teams. “Creating four product teams comprising front-end, back-end, iOS, and Android developers made all of the above possible,” says Sam. “Each team has a clear mission and will have distinct product outcomes (I’m only on week three of the Defining Outcomes course, so this part is a work in progress!).”

They received a lot of pushback from the engineers initially because it created complexities around code reviews, tech debt management, release processes, etc. and it created confusion for the lead devs with regards to how they would participate in the teams. “Now that we are almost ten months in, most of those challenges have been resolved,” says Sam.

Sam found it really helpful to use a diagram to demonstrate the benefits to them.

Sam created a diagram to help demonstrate the benefits of organizing teams by value stream as opposed to code base. Click the image to see a larger version.

The top diagram is how the team was structured to complete the technology transformation project mentioned earlier. The diagram on the top left illustrates what it would look like without the Program Manager/Product Managers.

In reality, Sam says they had what’s depicted on the top right—one program manager, two product managers, and several project managers at the top coordinating all of the scope and dependencies. The teams in this case were essentially focused on a list of prioritized and well-defined outputs.

When the project was completed, they moved people into cross-functional product teams so that they could empower the teams to focus on core aspects of their audience experience and more easily maintain parity across all of the platforms they support. Sam explains, “It introduced several new challenges, but the purpose of me creating this diagram was to help illustrate that they gain empowerment and a lot of autonomy—though it does make the release process more complicated.”

Creating a diagram helped illustrate that value-driven teams gain empowerment and a lot of autonomy—though it does make the release process more complicated. – Tweet This

Sam says POs struggled initially to help the teams plan across the different functions because teams were used to project managers defining their work for them: “It took time to transition to a more self-organized team, but it’s working well now!”

Himanshu Swaroop’s Advice: Get Everyone on the Same Page with Clear Strategy and Tactics

Meet Himanshu Swaroop, Transformation Consultant.

Himanshu Swaroop, a Transformation Consultant, shared his experience as an advisor at an insurance client where teams used to be set up based on functions. The company was facing several problems with their old approach. “They had a clunky old half-baked journey—half online, half on the phone, and it received very poor customer feedback. It was also very expensive for them to run, so they wanted a simpler online journey that would delight the customer,” explains Himanshu.

The company decided to set up a new multi-functional team to build a new online claims journey. The new team was a group of about ten people, some who had moved roles from their old teams and some who were new hires across design and engineering.

Himanshu calls out a few of the things that went well while setting up this new team.

They started with a clear product strategy, aligning on the top customer problems they wanted to focus on in the first six months.

They enhanced their collaboration through a design sprint. In the first few weeks, the team made a false start, forming around previous functional expertise. “This didn’t jump-start any collaboration,” says Himanshu.

After a few weeks of spinning their wheels, they realized the engineers still had no idea of the what and why of the features that had been selected to build. To jump-start collaboration, they held a design sprint with a designer, domain expert/business analyst, front-end engineer, and back-end engineer to corroborate the desirability and usability of some of the features with early customer feedback. This forced the participants to understand the customer opportunity in more detail. They uncovered new assumptions as well as architecture constraints. The participants came out of the exercise better aligned and improved their future collaboration.

They became more intentional about the new joiners’ onboarding journey to ensure anyone who joined the team was brought up to speed on their approach to cross-functional collaboration. For example, they held pair programming sessions and domain experts would lead “lunch and learns” to explain the business, customer context, and product strategy.

They ran early usability testing to validate the team’s direction. “Design and user research combined to do testing on early prototypes which improved confidence in the team’s direction,” says Himanshu.

And finally, the engineering team identified early that delivery pipelines required manual approvals from security and compliance teams. The team had to spend the first three months coordinating with security and compliance teams to understand the minimum standards on software that would comply with security and compliance requirements. There was no standard for product teams before this team and this was an improvement opportunity.

However, not everything went smoothly. Himanshu calls out a few problem areas that he’d recommend looking out for.

Early in the process, they divided into two teams with five members each. The first team had the domain experts, design, user research and the second had all the engineers. They decided to fully break down the prioritized features into stories and hand them over to engineers to deliver. As expected, this didn’t move any work for about six weeks. Then the teams re-arranged themselves—this time broken down by part of the customer journey and each team now having all skills—domain experts, design, user research, front-end engineer, and back-end engineer. This improved collaboration immediately.

Another issue arose early in the team’s formation: ambiguity in role clarity held the team back from taking action. It took some time for the organization and teams to formalize the responsibilities of each team member. Once these were clarified, the team could collaborate much better, e.g. who decides what to build (PM), who drives customer research (PM and Designer), who helps to navigate dependencies in the organizations (Architect). “Obviously everyone on the team gives input in each scenario, but it helped in each case how we moved forward,” says Himanshu.

On the technical side, the product team discovered after two months that they had to rely on three legacy applications in the organization to deliver the APIs they needed to deliver the product. “This road was laced with uncertainty and risk without this exploration. We wished we had uncovered this sooner,” Himanshu says.

Similarly, poor app documentation and code practices made collaboration difficult. When an architect with in-depth knowledge of the legacy architecture left the team after six months, it led to a painful process of understanding legacy applications without good documentation and coding practices.

Finally, one of the most difficult lessons was, “Old systems die hard,” says Himanshu. While the new teams were all aligned to new customer outcomes on claims, the budgets and incentives were still all aligned in the organization to functional teams. “The team was confused by this contradiction.”

Old systems die hard. – Tweet This

Reflecting on this experience, Himanshu shares the following tips for anyone who’s thinking about moving to cross-functional squads:

• Define roles of people in the product trios/multi-functional teams. It’s good to clarify what everyone’s role is. Nominate product leaders who can coach the individuals in the team.
• Team cohesion takes time. This is why activities like the design sprint can help jump-start collaboration and expose big assumptions in the work that the team is going to undertake at the start.
• Expose tech and organization dependencies early. Product trios and multi-functional teams are sometimes formed around legacy applications and legacy organizations. The sooner they uncover these show-stopping dependencies, the sooner the product trios can work through them with the support of their leadership. This may be working out how their solution utilizes more API-based services from legacy applications.
• Clarify outcomes and goals for the newly formed team. Leaders need to work extra hard to clarify the outcomes of newly formed trios. This includes explaining that their success as a team together will be measured based on these outcomes. Openly acknowledge that this might require executive leadership support as this might be at odds with the old incentive structure.
• Create a safe space to share progress. If this is a new way of working, make it easy for the team to share their learnings and for them to get coaching from seasoned product leaders.

Team cohesion takes time. This is why activities like the design sprint can help jump-start collaboration and expose big assumptions in the work that the team is going to undertake. – Tweet This

Teresa’s Advice: Acknowledge That Learning Will Be Slow at First

In the long run, this type of change is usually pretty powerful. It allows teams to move faster as they can deliver a full value stream without dependencies on other teams.

But the transition can be tough. In a front-end team for example, people collaborate with folks who have the same skills as them. They have a lot of shared ground to work from. In your new model, collaboration is going to take deliberate effort.

To start, it’s going to feel slow and worse. You’ll all need to learn to take the time to explore the diverse perspectives on your team and to work together to get to better solutions. What is likely to happen in the short run is you’ll mimic how you work now, but within your teams—meaning you’ll have a lot of hand-offs between the team members instead of collaboration. So I’d push hard to get people talking to each other and working together.

Some tactical ways you can do that as a member of the team:

• When you are working on something, bring others in on the thought process/design work/decision, even if it’s not part of their expertise.
• Involve more people in everything.
• Over communicate. Adopt the ethos of “working out loud,” where you make the work you are doing visible.
• Socialize with your team. If you are remote, do some Zoom hangouts or Zoom working sessions. The sooner you get familiar with your new teams, the easier collaboration will be.
• Get familiar with what everyone does. You might take turns sharing your work experiences with each other over lunch.

While shifting from functional platform teams can be hard, most companies eventually reap the benefits. Teams have a stronger sense of ownership, they are able to move faster with fewer dependencies, and it’s much easier to adopt an outcome mindset.

While shifting from functional platform teams can be hard, most companies eventually reap the benefits. – Tweet This

If you are in the middle of transitioning from a functional platform team to a cross-functional value-driven team, you aren’t alone. Come get support in our CDH Slack community.

The post Ask the Community: How Do You Shift From Functional Teams to Value-Driven Teams? appeared first on Product Talk.

Ask the Community: How Do You Shift From Functional Teams to Value-Driven Teams? was first posted on March 13, 2024 at 6:00 am.
©2022 “Product Talk“. Use of this feed is for personal non-commercial use only. If you are not reading this article in your feed reader, then the site is guilty of copyright infringement. Please let us know at support@producttalk.org.

The post Ask the Community: How Do You Shift From Functional Teams to Value-Driven Teams? appeared first on ProdSens.live.

You’ll often hear Teresa say that there’s no single right way to do continuous discovery. Something she might not say as often (that’s just as true) is that there’s no single wrong way to do discovery, either.

Because discovery involves changing the way you work on an individual, team, and even company level, it’s all too easy to make mistakes and missteps.

Let’s be clear: The fact that it’s easy to make mistakes is not an excuse for avoiding discovery. It’s just helpful to know what to expect so you don’t have to be too hard on yourself when something goes wrong. And maybe you can save yourself a little trouble by preventing some of the most common and basic errors.

The fact that it’s easy to make mistakes is not an excuse for avoiding discovery. It’s just helpful to know what to expect so you don’t have to be too hard on yourself when something goes wrong. – Tweet This

For today’s Ask the Community, we asked members of the Continuous Discovery Habits community to share a story about where they went wrong when they first started their continuous discovery journey. You’ll hear from: Leann Schneider, Product Manager at Plum.io, Sebastian Wramba, Product Manager at Netfonds AG (finfire), and Jelena Stajic, Vice President of Product at ScholarshipOwl.

If you’ve already begun to develop continuous discovery habits, maybe one of these stories will remind you of something you’ve experienced somewhere in your journey. And if not, we hope they’ll illustrate the importance of getting started and being open to learning along the way.

Ready? Let’s dive in!

Leann’s Story: Communicating the Results of Discovery Is Just as Important as the Discovery Itself

Meet Leann Schneider, Product Manager at Plum.io.

Leann Schneider is a Product Manager at Plum.io, a company that leverages Industrial/Organizational (I/O) psychology principles to accurately assess people’s potential—think an assessment that candidates or employees take to be placed in the right role within a company.

Leann says she “stumbled into product by accident,” but her educational background (a PhD in I/O psychology) allows her to bring scientific subject matter expertise to her role as product manager.

At Plum.io, Leann says, “The Product team’s purpose is to figure out what opportunities we should be pursuing and why, and to work with Design and Development to make that a reality.”

Leann’s Continuous Discovery Journey

One of Leann’s colleagues introduced her to Teresa’s work. After reading the Product Talk blog and Continuous Discovery Habits, Leann was ready to start putting some of the ideas into practice.

Describing the early phase of her discovery journey, Leann says, “Thinking back to where we started, it was in two areas—doing more interviews with our users and focusing on opportunities instead of solutions.”

We started continuous discovery in two areas—doing more interviews with our users and focusing on opportunities instead of solutions. – Tweet This

Setting up and conducting interviews was relatively easy because it didn’t take a lot of resources and they had support from their product leader. They would reach out to users who completed feedback surveys and interview them, offering to plant trees as a token of appreciation for each person who participated. “We’ve gotten great feedback on that. People are genuinely happy to help,” says Leann.

Leann’s Challenge: Finding the Right Way to Communicate Discovery

One of the more challenging aspects of introducing continuous discovery involved focusing on opportunities instead of solutions, especially when it came to stakeholders. Leann says executives would often give the go-ahead to conduct discovery on specific solutions, but she’d take a slightly different approach: “Instead, I approached the interviews broadly without a solution in mind. Then I came back with the recommendations, which often wasn’t the solution that was initially proposed, and have had to explain my work to get people on board.”

Reflecting on this approach, Leann’s learnings have mostly been on communicating the results of discovery. “I have found it challenging to succinctly explain the insights while also showing enough of my work to get people bought in on the recommendations,” says Leann. “It has been challenging to know who to bring in, who to convince, etc. An added complication is that our organization has grown a lot in the last year, so the people I need to get buy-in from have changed.”

Drilling down into one specific example, Leann says she was recently asked to do a round of discovery on a potential solution, but ended up uncovering evidence for a different opportunity that had a lot of promise. “We ran with it and gathered a ton of data on the opportunity and possible solutions, but I didn’t pause to think about how I needed to go back to my leader and the executive team to bring them along,” says Leann. This was especially important in retrospect because the new opportunity would have required a lot of resources to make it a reality.

Leann’s Key Learning: Communication Is Critical

Summing up the experience, Leann says, “I kind of went rogue, thinking that if I gathered enough evidence, it would convince others that it was a good idea. In reality it just ended up being frustrating. I didn’t get the buy-in I needed and was told to stop working on it, not because it was a bad idea, but because the executives didn’t understand the value.”

Luckily, this story ends on a more positive note. The designer Leann was working with took the time to visually outline the broader opportunity and possible benefits in a compelling way. Presenting this information to the leader got him on board with the opportunity. He asked for a tangible summary to share with the executive team, and this helped to achieve their buy-in. “I learned that I need to take a moment to assess new opportunities to see what level of input is required by my boss and executives, and work to bring them along even if the idea isn’t fully built out yet,” explains Leann.

Leann’s big takeaway from this experience? “Communicating the results of discovery, and the potential value of new opportunities, is just as important as the discovery itself. It’s fine to run with smaller opportunities yourself, but bigger ones will require plenty of resources, so it’s important to get buy-in from those who make the strategic decisions in the company.”

Communicating the results of discovery, and the potential value of new opportunities, is just as important as the discovery itself. – Tweet This

Teresa discusses the importance of showing your work and bringing stakeholders along in this keynote from Mind the Product 2017.

Sebastian’s Story: You Can’t Ignore Stakeholders’ Concerns (But You Can Challenge Them!)

Meet Sebastian Wramba, Product Manager at Netfonds AG.

Sebastian Wramba is a Product Manager at Netfonds AG, a company that supports independent financial advisors, private bankers, and insurance brokers and any combination of those from “lone wolves” to larger companies like private banks or networks. The platform and web application he works on, finfire, connects Netfonds with their customers, their clients, banks, and insurers.

While Sebastian works specifically with the insurance domain, he says they’ve recently integrated internal teams on the same platform so they can be more efficient and reliable in the services their customers expect from them.

Sebastian’s Continuous Discovery Journey

After working in software for a few years, Sebastian realized that product management was the path he wanted to take. “Like most beginners, I started with Marty Cagan’s Inspired and rather quickly stumbled across Teresa’s Product Talk blog,” says Sebastian. It was around this time that Teresa published Continuous Discovery Habits, where all the pieces in the blog finally came together, and it clicked for Sebastian.

To begin his continuous discovery journey, Sebastian wanted to get access to customers. He explains, “This is the best way to learn the most, the fastest.” He also began to shift away from feature-laden roadmaps to a more outcome-oriented perspective, which could be as simple as summing features beneath a common “What problem are we solving here?” headline.

Getting access to customers is the best way to learn the most, the fastest. – Tweet This

Sebastian’s Challenge: Trying to Charge Ahead With Customer Interviews Without Making His Case

Sebastian was keen to get started with customer interviews. There’s nothing wrong with this enthusiasm in and of itself, but because it was coupled with resistance from the rest of his business, it quickly transformed into a sticky situation. Sebastian describes his approach as “banging doors down”—and admits that it wasn’t the right way to move forward in that situation, especially because it was a moment when the company was struggling with their digital offering and customer communication was a polarizing topic. “I wanted to apply the CDH principle of weekly interviewing when the whole relationship to our customers was very sensitive and I didn’t try to explain what the goal or benefit was. I was just saying to stakeholders, ‘I need to talk to customers now!’”

Reflecting on what happened at the time, Sebastian says, “Other departments did not understand what I was going after, and honestly, not even my direct colleagues really understood what story-based interviews were about.”

Another issue Sebastian identified in hindsight was trying to approach all customers with a broad messaging tool (similar to Intercom). Sebastian wanted to use this tool to reach out to potential interviewees, but many of his coworkers were resistant to this idea, expressing concern that it would be hard to identify people who met their specific needs.

Not too surprisingly, Sebastian’s initial efforts to talk to customers were unsuccessful. He sums it up this way: “I didn’t get really far with the result. The company didn’t trust me that I somehow knew what I was doing. It was really hard to get users for an interview this way.”

Sebastian’s Key Learning: Trust Needs to Be Earned, But You Can Still Advocate for Yourself

Over time, Sebastian was able to better advocate for the importance of customer interviews, so he’s happy to report that he’s now able to approach customers himself. “But this trust has to be earned, especially in companies or domains with a more traditional background,” says Sebastian.

What has Sebastian learned from this experience? It’s something he believes Teresa mentions in Continuous Discovery Habits, so he should have listened, he laughs. “Take it slowly, take concerns from stakeholders, sales, management, etc. seriously, and address them in a sensible way,” says Sebastian.

But at the same time, Sebastian emphasizes that stakeholders don’t always know best, so don’t be afraid to advocate for yourself. “Even if you are new to a company, profession, domain, or all three, it’s perfectly fine to identify and challenge assumptions. Stakeholders might have great domain knowledge, but they might not know about building software or successful products,” says Sebastian. Keep in mind that they might have limited knowledge of the user base if they speak to the same customers over and over.

Even if you are new to a company, profession, domain, or all three, it’s perfectly fine to identify and challenge assumptions. – Tweet This

If you’re engaging in continuous discovery, you have the opportunity to speak with many types of customers (and prospects, churned customers, etc.). “Build your intuition by exposing yourself to user feedback through various sources as quickly and as much as possible, map out journeys and experiences, and over time, use this intuition during roadmap planning or discovery.”

Teresa is a big fan of starting small and then iterating. Check out some of her videos on organizational change:

• Introducing your organization to the discovery habits.
• Everyone loses the ideological war.
• Change is iterative.

Jelena’s Story: You Can’t Go From 0 to 100 All at Once

Meet Jelena Stajic, Vice President of Product at ScholarshipOwl.

Jelena Stajic is the Vice President of Product at ScholarshipOwl and she also runs the Product Manager in Pajamas YouTube channel. ScholarshipOwl.com is an AI-based scholarship matching platform that serves 9 million Gen Z students and ScholarshipOwl for Business gives brands a more effective way to run marketing campaigns targeting Gen Z. “Our mission is to eradicate student debt and we’re doing that with scholarship campaigns by connecting Gen Z students and brands,” says Jelena.

Jelena’s product team consists of two product managers who each lead one product and work with their own product trio. “Since we’re such a small team, we’re responsible for driving the core company strategy,” says Jelena. She sees her role as setting the product vision and strategy, but also acting as a mentor and coach who helps her team build autonomy and she tries to remove any impediments they face.

Jelena’s Continuous Discovery Journey

Jelena first learned about continuous discovery when she stumbled across the Product Talk blog in her quest to find a “proper” product development process. “I knew something in the way we used to just push features out was not working and made no sense to me, but I didn’t know how to do it better,” she says.

Once she discovered Product Talk, Jelena quickly learned about Continuous Discovery Habits, which she bought immediately and read twice. Next she joined the CDH community. “I knew this was the way to go, but I needed to get the rest of my team on board, too,” says Jelena.

Jelena’s Challenge: Expecting Everyone to Implement Every Aspect of Continuous Discovery at Once

To get her team on board with continuous discovery, Jelena developed a mini training workshop to teach them the basics and open up a conversation about how this approach might work for them. “Luckily, my team was very, very open and immediately excited and willing to have a go at it,” says Jelena.

However, despite her team’s openness to continuous discovery, Jelena still experienced some challenges and setbacks.

“The biggest mistake was expecting to go from 0 to 100 at once, more precisely, expecting to have every single element of continuous discovery implemented at once,” says Jelena. “With the speed of work we do in our team, it was unreasonable to implement it all at the same time, so the fact that I tried to push it all at once backfired a bit and all of us were super overwhelmed.”

The biggest mistake was expecting to go from 0 to 100 at once, more precisely, expecting to have every single element of continuous discovery implemented at once. – Tweet This

Another misstep Jelena believes she made includes building opportunity solution trees based on internal input rather than customer input. “I’m 100% sure Teresa warned about this mistake, but I guess we needed to learn some things the hard way,” says Jelena. As a result, her first opportunity solution tree was filled with opportunities her team thought were customers’ needs, pain points, and desires rather than what they’d heard directly from customers. “Needless to say, we ended up pursuing opportunities that we thought mattered, but brought no results,” Jelena adds. 

Another challenge that Jelena says she’s still facing is getting pushback from certain team members who aren’t very willing to attend customer calls. Jelena’s approach has been to share what the team has learned from customers and hope that these insights will convince those hesitant team members about the power of discovery.

Finally, Jelena says she learned that testing assumptions is not the same as building minimum viable products. It’s been a challenge to break out of the MVP mindset. “Now we know that it’s about learning what can make or break all the assumptions we have and we’ve gotten better at testing that rapidly with our customers instead of jumping to develop an MVP of a feature,” says Jelena. She and her team now run prototype tests and smaller scale simulations inside and outside the product. 

Jelena’s Key Learning: Focus on Just a Few Areas at a Time

If she had the opportunity to go through it all again, Jelena says, “I’d start from what I believe to be core to the continuous discovery practice—interviewing and opportunity solution trees—and then I’d work on getting better at testing assumptions, ideating solutions, etc.”

Why is interviewing so important to Jelena? “It’s not just about talking to your customers but how you talk to the customers to really extract their paint points. I learned that it’s not just the customers’ experience around our product that matters, but their life experience and how our product slots into their life to make it better.”

Jelena says she’d pick one to three things to get good at each quarter. “It’s a process. To me it’s about doing a little bit better every day instead of trying to do it all at once.”

Finally, one of the tactics Jelena is interested in exploring further is making sure continuous discovery habits are a priority when hiring anyone new for her team. She says, “I’d argue to hire with continuous discovery in mind, either for people who already have the experience, or people who are willing to learn it. I think it’s important to set clear expectations from day one if this is the way your organization wants to go—and it should.”

I’d argue to hire with continuous discovery in mind, either for people who already have the experience, or people who are willing to learn it. – Tweet This

Teresa spoke about choosing one habit and iterating from there in her 2023 Product at Heart keynote. Give it a watch (or a read) if you need help choosing where to get started.

You never have to face your challenges alone. In the Continuous Discovery Habits community, you’ll be supported by like-minded peers who have experienced similar situations and are happy to help you overcome them. What are you waiting for? Come join us there!

The post Ask the Community: What’s a Mistake You Made Early in Your Continuous Discovery Journey? appeared first on Product Talk.

Ask the Community: What’s a Mistake You Made Early in Your Continuous Discovery Journey? was first posted on January 31, 2024 at 6:00 am.
©2022 “Product Talk“. Use of this feed is for personal non-commercial use only. If you are not reading this article in your feed reader, then the site is guilty of copyright infringement. Please let us know at support@producttalk.org.

The post Ask the Community: What’s a Mistake You Made Early in Your Continuous Discovery Journey? appeared first on ProdSens.live.