Have you heard? My new book Continuous Discovery Habits is now available. Get the product trio's guide to a structured and sustainable approach to continuous discovery. Leading a product team (or several teams) comes with its own set of challenges that’s often similar to but distinct from the hurdles individual product contributors face. There’s pressure coming from all directions—your company leaders expect you to deliver business results while your product teams may be working in silos, misaligned with their peers, or unclear on core product skills and concepts.
And if you’re trying to guide your teams toward being more empowered and autonomous, this is a process that takes dedicated time and commitment.
That’s why it’s especially enlightening when you encounter a product leader who is willing to openly share the challenges they’ve faced. Their transparency helps us see that many product teams are on a similar journey.
Stephanie Leue, former Chief Product Officer at Doodle, is one of those leaders. She regularly shares her learnings and insights on LinkedIn and recently took some time to chat with Teresa for this Product in Practice about her teams’ experience with continuous discovery.
Do you have a Product in Practice story you’d like to share? You can submit yours here.
You can watch the video or read a lightly edited transcript below.
Editor’s note: This conversation happened on February 7, 2024. As of publication, Stephanie Leue is no longer at Doodle.
Full Transcript (Lightly Edited for Clarity)
Teresa Torres: Welcome, everybody. I am very excited to be joined today by Stephanie Leue. She is the Chief Product Officer at Doodle, and we are going to dive into her story about how her team navigated some tricky roles and responsibilities and came out the other side in a much better place. Stephanie, I’m excited to have you here.
Stephanie Leue: Yes, thanks for inviting me to your podcast. I’m excited as well.
Meet Stephanie and Learn About Her Role at Doodle
Teresa: Excellent. Let’s start with, tell me just a little bit about your role in your company.
Stephanie: Absolutely. Most people I speak to actually know Doodle. They used it in university or they’re still using it. We’re a scheduling company, so we make finding mutual availability between groups of people fairly easy. We’re a 14-year-old company that started off as an ads business, and we’re transitioning into a SaaS business.
I’m now Chief Product Officer for almost 19 months, and I started at Doodle 2 years ago as a Director of Product for the scheduling domain and got promoted quite quickly into a CPO role and since then have the luck to work with a really ambitious team.
Teresa: Excellent. Congratulations. Tell me a little bit about your team structure: how many teams, who’s on it, who reports to you?
Stephanie: Absolutely. We have five product managers, one UX researcher, five designers—one of them director of design, leading the design team. All product managers report to me, and we have five product teams up and running.
Teresa: Okay. Yes, great. It sounds like you are responsible for product, design, and research. Is that fair?
Stephanie: I am. And product marketing as well.
The Role of Continuous Discovery at Doodle When Stephanie Joined
Teresa: Okay, so I understand from our LinkedIn conversations that your team recently had some really great discussions about the role of user research, the role of continuous discovery, who does what. I definitely want to get into those conversations and that debate.
But before we get there, tell me a little bit about what was going on in the organization that inspired that debate. What symptoms came up? What was the day-to-day like that inspired this?
Stephanie: Yes, I assume our story is a little bit different actually, because there was nothing internally inspiring that discussion. It was rather me trying to push my teams to get to that point.
One of the things I started right when I joined Doodle was a transition from the classical feature factory towards a product-led organization.
We were literally a top-down product organization. Someone had a feature idea—mainly someone from the board or the CEO or the former CPO. They told the teams what to build, the teams built it. We more or less tried to keep up with competition instead of finding our very own unique value proposition.
When I joined, I wanted to transform that organization because I’m so convinced that only if you have autonomous teams that own their space and their domain and that do proper research and that really understand customer problems, that you will be able to also really build amazing products. We weren’t there when I joined.
The first thing I did when I joined was I introduced a process that I also used at Contentful. Contentful was high-performing, autonomous teams. They’ve done all things by the books. It’s been amazing.
I felt like, okay, if we only use the same process we had at Contentful and we’re using the same thing at Doodle, by involving everyone, talking to people and trying to get them on board and get their feedback. Just introducing the process from discovery to define, to build, to measure, we will be all set up for success because the teams are mature enough to get there.
And actually, I was wrong.
Teresa: Yeah, if only it was that simple.
Stephanie: That’s where we started.
Teresa: So tell me a little bit about what went wrong.
Stephanie: To be honest, in retrospect, nothing really went wrong. I think I just had too high expectations. My expectations were that actually, the team is super mature. Everyone was super hungry. We have a really excellent team and people who are eager to solve problems so they understand why it’s important. No one was stopping us. Neither did we have to convince the CEO nor other teams that we want to work this way.
We were literally set up for success. But still, transforming an entire organization and all of their ways of working into a more product-led setup is a challenging thing.
We were literally set up for success. But still, transforming an entire organization and all of their ways of working into a more product-led setup is a challenging thing. – Tweet This
If I look at it in retrospect, what I learned is that actually we’ve had a lot of progress, but the teams naturally tended to focus rather on the build and measure phase and a little bit on the define phase, but they more or less neglected the discovery phase because we already had so many things that we knew we had to deliver that actually no one was questioning that those things are needed, so there was no need to do proper discovery.
Teresa: This is really common. I think especially in a company where there’s a history of feature factory. We have plenty of ideas. We’re drowning in ideas. Our backlogs are full. Why do we need to go find new ideas?
So you came into the role. You have this grand vision. You want your teams to work the way they worked at your previous company. I know in a lot of feature factories, product teams don’t engage with customers that often. Maybe they get pulled into sales calls or they get pulled in to help with support tickets.
Tell me a little bit about the habits of the teams when you first arrived. Were they engaging with customers? What was the culture like around customer centricity?
Customer Centricity Is Key to Product Culture at Doodle
Stephanie: Yes, that was one of the reasons why I didn’t doubt a single second that we were ready for discovery as well because we’ve done a pretty decent job. We had a really good data team and the data team was gearing up in order to provide better data to all teams.
We were able to analyze all funnels, all data. We were really in a good setup. We’re not in a setup where we have access to data ourselves, so we have to rely on a data team to fulfill our data requests, but they’re pretty fast and good in prioritization. We’re halfway there when it comes to data. Good setup for a company like ours, right? There’s always more room, but we’re good.
We have a super solid setup when it comes to CX teams and CS teams. There is a strong bond between CX, CS, and product teams. The CX teams gather a lot of feedback. They sort the feedback in Jira, tagging it by problems, sharing it with product teams. We have CES scoring. We’re collecting customer feedback through CES scores.
We have data available all over the place actually, right? It’s accessible for everyone. It’s shared in Slack. We know the problems. We listen to customers. We even talk to customers. My team talks to customers.
We haven’t had the research function in place. That is something that I brought into the organization. I was lucky because I had a product owner and I wanted to get rid of product owners, but one of my product owners told me that she would love to become a UX researcher. So we transitioned her into that role and she’s incredible. We do have UX research meanwhile as well. I’d say purely from a setup, we’re in really great shape actually, right?
The Big Debate: Who’s Doing What?
Teresa: Okay. What led to this debate? What sort of arose that led to this conversation around who’s doing what?
Stephanie: Suddenly you have all the insights. Everyone is talking to each other. Everyone is looking at customer feedback. Everyone is talking to customers, looking into data. All of that is happening and still, people build features. Obviously, there is a disconnect, right?
Teresa: Yes. The challenge was between: we have all this data, but we’re still building what we were always going to be building.
Stephanie: Exactly. Then in retrospect, we argue why the features we’ve built were the right things to build. We have always found reasons why the things we’ve built were really high value and why they were solving the right problem. In retrospect, it’s always easy to connect the dots and I think we were good at connecting the dots in retrospect.
Teresa: Yes. This is one of the hardest things to sort of expose on a team is that it’s one thing to build habits, it’s another thing for those habits to be effective. I think I can have a good conversation, but I have to act on that conversation, right?
It’s one thing to build habits, it’s another thing for those habits to be effective. – Tweet This
Stephanie: Exactly.
Teresa: One of the things I think I’ve written in the past is if your backlog or your roadmap or your idea log—whatever you’re going to call it—isn’t changing based on what you’re learning in discovery, there’s a disconnect there.
Okay. You had five product teams, a user researcher who was new to the role. How did you try to address this? What did you do to try to improve this?
Stephanie: We set it up as individual goals for all product managers to do continuous discovery. We established processes for the researcher, PMs, and designers to do continuous discovery. We established a budget for the team so they can do more research and structure research. We onboarded to Maze in order to do better research. We sharpened our prototyping skills. We collaborated more closely with the CX teams to also use Intercom to acquire more customers for interviews.
We’re a scheduling tool, so obviously setting up the whole process is not a big deal. We have booking pages in place. You can expose them through Intercom. We have 60 million customers on file, so it’s also not a scaling problem. We have access to customers.
Literally, from the outside, we’ve had the perfect setup and we’ve tried everything. The teams were ready. They’ve read your book. They understand what continuous discovery is. We have had the functions in place and still, although we’ve done all of that, the connection between discovery and delivery was completely nonexistent.
Teresa: Okay.
Stephanie: Here’s the thing. I didn’t stop. I continued saying, ‘Can we do continuous discovery?’ I heard all of these tiny little problems. Yes, we do. We are using Intercom, but no one signs up for interviews.
Or yes, we’re doing interviews, but here are all the problems and we want to solve them, but not yet, right? All these tiny little things.
A Workshop Kicks Off a New Commitment to Discovery
Teresa: It sounds like recently, you had a workshop that had a big impact. Tell me a little bit about that.
Stephanie: Exactly. One of the insights I had when I reflected on 2023 is that the team has done an amazing job when it comes to the define, build, and measure phases. We tripled the amount of releases. We created impact. We saw that CES scoring went up.
I wouldn’t say that we ignored customer feedback at all. We were already choosing the right problems to solve, but we still didn’t do a proper job in doing discovery to its best.
I initiated a workshop as a kickoff for 2024 saying, team, I see we’ve done a great job in the define and measure phase and build phase, but I feel like we’re still lacking the discovery phase. Everyone was nodding.
We went into that workshop and initially, I wanted to spend parts of the workshop on discovery and a little bit on define as well, because we can do better in the define phase as well, but we had to restructure the entire workshop on the go because we figured out there is so much to do in the discovery phase that actually, we need to solve that first.
My key learnings from the workshop were three things. Number one: My team had a hard time defining what a problem is, what a hypothesis is, what the difference between a hypothesis and an assumption is.
How did we figure that out? I asked them to define a problem statement for the number one problem we’re all aware of, where we do have research and data and we all know that this is one of the biggest problems and I asked them: turn that into a problem statement. Fifteen people and it took us 20 minutes to come up with a problem statement that was a true problem statement.
That’s where it starts already. If your team isn’t even able to create a proper problem statement, then obviously, you have a hard time defining the problems you want to work on.
If your team isn’t even able to create a proper problem statement, then obviously, you have a hard time defining the problems you want to work on. – Tweet This
Then we went to the next step and I said like, okay, now we do have a problem statement, let’s create a bunch of hypotheses for this problem statement. Same thing. We struggled to define a proper hypothesis for that problem statement.
If you can’t do such things—if you can’t really even articulate problems and hypotheses, if you don’t know the difference between a problem, hypothesis, and assumption—then obviously, you need to start from scratch again and that’s what we did.
Keep in mind: We’re really a mature team. My teams read all of these books, they do good trainings, they go to conferences, but they were lacking these tiny little details, and, to be honest, even I struggled.
That was a good exercise and that was learning number one: Breaking it down into its smallest pieces and aligning on something and learning together as a team, I think unblocked a lot.
The next thing we learned is that actually, we struggle to understand how we prioritize and how we do research.
It felt so overwhelming for the teams on the one hand that they felt continuous discovery is only interviewing customers and we need to interview customers regularly, every week, everyone.
Then they had a hard time understanding that if they already have a long list of problems, now talking to customers might also mean that they talk to customers that are not even facing the biggest problems or they talk to customers that do not fall into the target market we defined, or they talk to customers that don’t even use the product that they are working on or the domain that they are interested in. That’s where the whole struggle started.
One thing we identified was, for us, continuous discovery does not only mean talking to customers every week, it also means we can validate all of our assumptions through various tools.
For us, continuous discovery does not only mean talking to customers every week, it also means we can validate all of our assumptions through various tools. – Tweet This
It can be prototyping, fake door tests, internal interviews. It can be anything. We have 5,000 tools and continuous discovery does not mean just talking to customers, it means finding exactly the right tool to prove or falsify an assumption.
And the more evidence you have for your assumption, the less investment you need to make into the validation process, right? The lower evidence you have, the more investment you potentially put into validating or falsifying your assumption. That was definitely also holding my team back.
Then the third thing is—and I think this is something every team is facing—the team was on fire. We have so many features to deliver. We have so many things up and running.
We have some engineering teams that are so high-performing that they put a lot of pressure on PMs saying, ‘What’s next? What’s the vision? What are we going to build?’ Then nothing is lined up because the PM says, ‘I’m now in the problem space and I have nothing prepared for you. Do some tech debt.’
Then I come in and say, ‘We can’t waste engineering time now for six weeks on tech debt. Can’t we keep them somehow busy with something?’
Then the PMs are in this constant stretch between everyone is pushing them in any direction and they rather want to satisfy the engineering teams because those are the people they work with every single day.
These are the three problems: Not knowing the details and how to define problem and hypothesis, not knowing how to do proper research, and mixing up continuous discovery with just interviewing customers. And the third problem, this constant stretch between being pushed into different directions from different people. We needed to break that vicious cycle.
Teresa: It sounds like this workshop surfaced a lot of, not sort of big challenges, more of the little connecting glue challenges that so often are the real obstacles in an organization. What happened next?
Stephanie: Magic. Literally magic. I’ve just sent kudos to my team.
The workshop was running for one and a half days. The next day I went back to Zurich. My team stayed in Berlin. We’re distributed teams across different countries. They stayed in Berlin in the office. Each team met for their domain with the PM, the researcher, and the designer, and they just mapped the entire problem space because we’ve never done that.
They had ideas of the problems to solve. They have all the research and data at hand, but they were never really sitting down in order to map their individual problem space. They took the time and I think they were super surprised that it didn’t take any longer than two to three hours to map the entire problem space because everything was there.
Since then, each team on each domain is just continuously meeting. There’s not a single day where they didn’t talk about the problem space, didn’t talk about evidence, didn’t talk about hypotheses.
I would say, since the workshop was only two weeks ago, we’re in a really magical space right now where we have a very solid mapped-out problem space. We have a very nice research matrix that helps us to understand which research method is the right method for which kind of hypothesis.
I feel like designers and PMs bonded so strongly in the past two weeks, like never before. I feel like it’s a complete transition from everyone in my organization and it’s just magic.
Teresa: That’s so great to hear. What it sounds like to me is that—and this makes a lot of sense in an organization rooted in the solution level—is that your team just made a big jump from focusing on solutions to really starting with problems or opportunities and really understanding what that means and what that looks like.
I think that always raises the level of conversation and makes it a lot easier to collaborate because there’s less opinions in that problem/opportunity space. It’s much more about the customer and not about how I think the solution should be versus how you think the solution should be.
Fostering Collaboration Between User Research and Product
Teresa: One of the things that you shared with me privately was you have one researcher and five teams, and one thing that came out of this was just looking at how they work together. Who’s doing what? Do you want to share a little bit about where you landed there?
Stephanie: Yes, absolutely. I wouldn’t say we have a full answer to that question yet, but there were some really, really interesting insights. One aha moment for me personally was the moment when a PM explained to the designers how much prep work they are actually doing that seemed to be hidden to designers.
Designers felt a little bit like the PMs are the kings and queens in the room and they are always the decision-makers and they felt like all of their decisions are rather biased or not foundational enough or not based on research or insights. It’s just like gut feeling or they just come up with things.
When my PMs explained to the designers how they actually approach their work and they explained what an ICE scoring is or how they validate certain things or how they look at data every single day, the designers came back to the PMs and said, ‘We didn’t know that you put so much effort into preparing each of the refinements and sprints. We didn’t know that the decisions you make are based on so many insights. Why didn’t you just share this with us? Why aren’t we part of the process?’ It’s a transparency problem.
If you ask me, did the roles change? I don’t think so. They have the same roles. It’s just the level of transparency increases on the PM side, which gives the designers, researchers—and hopefully also engineers—more confidence that the decisions we make are better.
When the level of transparency increases on the PM side, it gives the designers, researchers—and hopefully also engineers—more confidence that the decisions we make are better. – Tweet This
I’d also say that because there’s more transparency, now everyone in the room has a say because they obviously have found common ground and that’s really cool.
Teresa: It sounds like a giant step in the right direction from a product trio collaboration standpoint. That’s really great. You have five squads of product managers, designers, and engineers. Is that right?
Stephanie: That’s right.
Teresa: But you only have one researcher. Now each of your squads has a problem space. They’ve got full backlogs, just like everybody on the planet. How is that researcher working with your teams?
Stephanie: I introduced flight levels to my teams. I think teams often struggle to connect the dots between vision, strategy, and execution or opportunity space, right?
Since you only have one researcher, that researcher is always stretched between foundational research, strategic research, and day-to-day research.
Introducing the flight levels helped my teams to understand where they are actually operating. I always feel like each flight level also needs a different kind of research and a different kind of treatment.
Introducing flight levels helped my teams to understand where they are actually operating. Each flight level also needs a different kind of research and a different kind of treatment. – Tweet This
I now have my UX researcher focusing on the problem space with the teams. What she does in the next couple of weeks is actually help all teams to define the problem space.
The teams are mature. They know how to define a problem space. What she does is she joins a couple of workshops. She shares her insights again. She does some course correction here and there. She created a matrix of tools that we all can use as a team.
Then there are some tools where we really need her for unbiased customer interviews, for example. That’s something where my PMs are not super trained right now. My designers are trained a little bit and they are getting better. Some are better than others.
She is rather a coach. Sometimes she’s executing things herself, but mainly she’s coaching the teams to do interviews themselves as well.
For more foundational research, for example, we’ve done jobs-to-be-done research early last year. She’s the one doing this foundational research all by herself. She pulls in the PMs and designers she needs for certain sessions.
By differentiating all of these different flight levels and defining where everyone feels confident to do research themselves, guided or unguided, we definitely also empower everyone in the organization to do better research themselves, but it’s all orchestrated by my UX researcher because she’s just amazing. She’s like four people, really. She’s mind-blowing.
The 3 Flight Levels That Guide Product at Doodle
Teresa: That’s great. I know on LinkedIn you shared a visual of these flight levels. Do you want to just walk through them? We’ll link to that for sure, but do you want to just walk through them?
I think you had three different levels. And then talk a little bit about your product teams are working at one level. Your researcher is working at the other levels.
Stephanie: Exactly. What we’ve done is we’re using the decision stack from Martin Eriksson. Fairly simple. I think we see similar setups also in other tools.
The vision is flight level one for me. It is the most aspirational part of my entire product setup. It’s very fluffy. It’s blurry. It’s very future-oriented. We never know if it will come true or not.
It is hard to do true research for a product vision. What we have done is the jobs-to-be-done research, which now influences all of the three flight levels, the opportunity level, the strategic level, but also the visionary level.
We’ve done the classical target market research, which is important for vision as well. We’ve built a prototype based on insights from the jobs-to-be-done research and all the problems we are aware of. We’ve come up with some ideas of what the future of Doodle will look like. We created some prototypes. We turned these into a vision prototype, a very nice video.
There is some foundational research that I did with one of the designers and based on the foundational research that we have done in the past couple of months. This is more or less ongoing, but we’re not putting too many resources into that area for now because it is very well defined and understood. We will have to iterate on it, but it’s okay to not invest more capacity into that right now.
On the strategic level, we’ve done the jobs-to-be-done research. This has been a crazy change for the entire team because that gave us so much focus and we still refer back to the main three jobs to be done that we identified during this research that I would say this is a good foundation for the strategic level. Nevertheless, my PMs, for their domains, also need to define strategies in order to connect the vision to their opportunity space.
This is something we’re not super good at right now. We have some ideas, but we’re lacking some tools and we’re lacking capacity in order to do proper evaluation of the longer-term strategy for each of the domains. This is something we need to fix in the next couple of months for sure.
We decided, for now, to first focus purely on the problem space and that’s where each of the PMs has an idea of the most pressuring problems to solve in the next three to six to nine months. This is where they do collaborative research with the designer and the PM and they are guided and coached by the UX researcher.
Teresa: Okay, so it sounds like your three levels: The highest level is product vision. The second one is product strategy. The third one is the opportunity space that each team is responsible for.
Stephanie: Exactly.
Teresa: Your trios, or at least the product managers and the designers, are responsible for the research at the opportunity space level, but they get guidance from your researcher.
Stephanie: They are.
Teresa: Then is the intent that the researcher will also focus on more strategic, the product strategy research? I know you mentioned your more senior PMs also contribute at that level as well.
There’s sort of gradations of, there’s sort of the day-to-day work in the opportunity space. There’s sort of the longer horizon work in the strategy space. Maybe eventually all of that will feed back into an evolving vision over time.
Stephanie: Exactly. In my experience, you can’t focus your teams on all three levels at the same time. Mapping the opportunity space takes time and it slows down things. That is something we need to embrace and where we also need to give room to the teams.
I feel like putting pressure into the teams and saying, don’t only map the problem space, but also fix the strategy part and contribute to the bigger picture, that’s not necessary. The bigger picture is good. It’s well done. It’s well researched. It’s really guiding the teams already well enough.
We have a high-level idea for all of the strategic pieces. We know where we want to go high level, so it’s fine for now to focus on a problem space. At the same time, I feel like all domain owners or teams also know that they can evolve and grow into a more strategic role, which is nice because it gives them an idea of where their role will evolve into as well.
Teresa: I think you’re also hitting on something that I think is a key role for researchers, which is if you have five teams that each have their own problem space, there’s sort of this research that cuts across all of them.
Which I think starts to feed back into that strategy level, which is what’s the arc across all of these? What are the trends? Where are we going? What direction should we be heading across all of these?
That I think is really hard for an individual product team to do because they’re so focused on their backlog versus somebody who has the research skills and the time horizon to look at, okay, it’s great that we’re getting good at this opportunity level. How are you pushing up into the strategy level?
Stephanie: Yes. I’m also wondering if you can really find a hard line between opportunity space, vision, and strategy because a problem—let me name one. One of the jobs to be done in our case, for example, is that our customers want to build their own brand. This is something that influences my vision, right? I do have an idea of how a Doodle can support our users to build their own brand, but that’s also a today problem.
We can do things in that problem space already as of today, but if my teams have the bigger picture in mind, they also understand how they can solve this problem with the future state in mind, potentially.
You’re always connecting the dots between the bigger vision, the strategy, and your day-to-day work if there is a clear enough and well-argued vision in place.
You’re always connecting the dots between the bigger vision, the strategy, and your day-to-day work if there is a clear enough and well-argued vision in place. – Tweet This
Teresa: Yes, 100% agree. I think it’s so easy to think about it as it trickles top-down vision, strategy, opportunities, but I think what a lot of teams miss is it also trickles back up.
There’s this concept in the sort of academic strategy world of emergent strategy. All those decisions we’re making at the individual team level start to influence the strategy and the vision—as they should, because that’s what we’re learning directly from our customers.
Stephanie: Exactly. Yes, absolutely agree.
Stephanie’s Final Thoughts and Takeaways
Teresa: That’s fantastic. Stephanie, I really appreciate you taking the time to share your story. Is there anything else that you would like to share before we wrap up?
Stephanie: I just want to encourage everyone to give time to their teams to really map the problem space. Because I’m convinced once you’ve done the hard work, you will become faster and faster and faster and you will train this muscle. This is so important.
I want to encourage everyone to give time to their teams to really map the problem space. Once you’ve done the hard work, you will become faster and faster and you will train this muscle. – Tweet This
At the same time, in my role, to be honest, it’s super hard telling my teams that it is okay to keep the engineering teams busy for the next three, four, or five weeks so they can take time to map the problem space. It is a decision that breaks my heart because I have to argue why we’re potentially not releasing the biggest impactful things in the next three to four to five weeks.
Finding this fine balance between, when is the right time to give the teams enough freedom to do so, and at the same time, embracing that it will take a lot of time in the very early beginning, but become much easier over time. This is something that is not super easy in my position, but something I would encourage every product leader to do.
Teresa: Yes, I second that for sure. It also sounds like you did a really amazing job of creating an environment where your team was comfortable sharing those little teeny-tiny obstacles or blockers. That’s amazing. I know it’s really hard in a leadership role to get a team to surface those concerns. Kudos to you. I know that’s not an easy process.
Stephanie: Yes, I think I sent these kudos right away to my team because they are just super cool and eager to really always learn and improve. It’s the people that make me successful so I can make people successful. It’s a team effort.
Teresa: Excellent. I’m excited to see where Doodle heads because it sounds like the team is embarking on a pretty good direction and I’m excited to see what comes from it.
Stephanie: Same here. Thanks.
Teresa: All right. Thank you so much.
