Improving Core Web Vitals by 43%

Core Web Vitals have become increasingly important in recent years as they play a significant role in determining a website’s search engine ranking. Core Web Vitals measure the user experience by looking at how quickly a page loads, how quickly it becomes interactive, and how visually stable it is while loading. By optimising Core Web Vitals, businesses can improve user experience, reduce bounce rates, and ultimately drive a higher rate of conversion.

At Photobox, we realised we were trailing behind competitors in this area and that by improving our performance scores we were likely to see improvements in key metrics such as conversion, engagement and retention, e.g:

My team run the ‘Shop’ portion of the Photobox website, which is a React based application serving the product selection part of the experience for customers.

We knew that to move our scores meaningfully upwards would require significant investment and so set about demonstrating to the business the importance of scoring well in this area and the likely returns we could expect from our efforts. After a successful internal campaign, we were given the go-ahead to invest 25% of our time into this work over the course of one financial year and given a target to improve of 20% in order to meet competitor benchmarks.

We then developed a long list of potentially impactful improvements and used the RICE formula to prioritise these, slotting them into the roadmap in a way that would ensure we delivered high value improvements early to reassure stakeholders of the difference we would make to our scores by the end of the year.

Our 17 most impactful improvements

  1. Upgrading Node: We upgraded to the latest version of Node, which allowed us to take advantage of the latest performance improvements and bug fixes.
  2. Removing Ramda: Ramda is a functional programming library that we were previously using, but we found that it was slowing down our site. By removing it, we were able to improve performance.
  3. Refactoring Extended Fetch: We refactored our extended Fetch API to improve performance and reduce bundle size.
  4. Refactoring KOA: We also refactored our KOA middleware to improve performance and reduce bundle size.
  5. Reducing bundle sizes: We used tools like Webpack Bundle Analyzer and Code Splitting to reduce bundle sizes, which in turn helped to improve page load times.
  6. Removing props: We removed unnecessary props from our components to reduce the amount of data that needed to be transferred between the server and client.
  7. Deprecating unused code: We went through our codebase and removed any unused code, which helped to improve performance and reduce bundle size.
  8. Delaying experiment code: We delayed rendering of custom experiment code to improve initial load time and First Contentful Paint.
  9. Resolving garbage collection errors: We resolved any large garbage collection errors that were causing our site to slow down significantly or in some cases timeout altogether.
  10. Refactoring Apollo Client: We refactored our Apollo client to improve performance and reduce bundle size.
  11. Implementing high fetch priority: We implemented high fetch priority for essential resources, which is recommended by Google and helped to improve page load times.
  12. Cleaning up Redux payload: We cleaned up our Redux payload to reduce the amount of data that needed to be transferred between the server and client.
  13. Optimising images: We optimised our images to reduce their file size, which helped to improve page load times without compromising the importance of images in showcasing our product catalogue.
  14. Extending caching: We extended our caching to reduce the number of requests made to the server, which helped to improve page load times.
  15. Removing unused JavaScript: We removed any unused JavaScript to reduce the amount of data that needed to be transferred between the server and client.
  16. Increasing lazy-loading: We increased lazy-loading where possible in order to reduce the amount of data that needed to be transferred between the server and client.
  17. Optimised ESLint: We optimised our ESLint configuration to improve performance and reduce bundle size.

As you can see, bundle sizes were the biggest contributing factor to our lower Core Web Vital scores and a significant proportion of the work we undertook was to reduce these across our stack.

Each quarter I reported on our progress towards the 20% target and was excited to see we were achieving beyond this every time thanks to the hard work of the team.

At the end of the financial year we had managed to achieve a huge 43% improvement in our Core Web Vital scores and we were now in the top performing quadrant against our benchmarked competitors.

Work is now underway from our SEO and Analytics teams to evaluate the commercial impact of our work this year. I’m looking forward to sharing the results!

Working from home changed my life

I am fortunate enough to be someone who benefited enormously from the shift to remote work that came from the COVID19 pandemic.

I had always found commuting to be a challenge for both my mental and physical health. When I worked for Mind, I commuted 4.5 hours a day from Brighton to East London. It was so exhausting that I was relieved to eventually move to London, only to find that the tubes are too packed in the morning to board, so I traded my long train journeys for a gruelling and hazardous cycle through central London each day.

When the pandemic hit and everyone who could was required to work from home, I was initially worried that mixing my work and home environments would be lonely and difficult to switch off from, but I soon found the benefits outweighed the downsides so significantly that the transition eventually began to feel absolutely life-changing.

Suddenly it was 5pm and I was already home. I could say yes to things I’d previously considered to be for people without jobs. I became more community orientated. I could stay out later in the evenings without fear of the early alarm. I could wake up to natural light and casually sip coffee while I checked my morning Slack messages from a desk at the end of my bed.

Eventually I also became aware of the financial benefits too. As the months rolled by, I noticed my bank account looking significantly healthier than usual. I was awake for fewer hours and the physical demands on my mind and body were reduced, so the recommended three meals a day which I’d always found weren’t enough to get me through suddenly made sense. Coffee was now something I could enjoy for pennies rather than pounds and exercise was a safe lunchtime run rather than a pricey after hours gym membership.

Throughout the pandemic, I noticed business leaders fearing the trend to working from home would lead to a decline in productivity for employees. I was surprised by this as I found the very opposite to be true – I was more productive than ever and finally enjoying my working days. Rather than battling through the constant distractions and piecing together a functional work station each morning, I suddenly had instant access to a peaceful, comfortable and productive work environment from home. Collaboration with colleagues had never been easier as the time-wasting palaver of looking for private space and usable stationary had become a thing of the past. Co-working was now an effective and fully digital experience, a simple click away.

Since the threat of COVID19 has gradually reduced, the ‘return to work’ discussion is beginning to emerge, with many companies expecting employees to return to the office at least a couple of days a week. For me though, there’s no going back to that life now I know how positive and productive the alternative can be.

Side hustling towards financial independence

Like many semi-nomadic tech workers, I’ve recently become interested the FIRE movement, not necessarily with the intention of retiring early, since I love my work, but with the option to have financial security and freedom from the constraints of having to work in the future.

One common approach to the wealth building phase of FIRE is the concept of a side hustle, a job that fits around the 9-5 and provides extra resources for savings and investment.

Early last year, I gave a lot of thought to the kind of side hustle that would make sense for me. My criteria were:

  1. It had to fit neatly around my full time job – I didn’t want to be in the position where I felt stressed juggling the two or trading one off against the other
  2. It had to be simple enough that it wouldn’t require any additional mental energy to complete – again I didn’t want to be in the position of sacrificing my commitment to one in favour of the other
  3. It had to pay enough to make the additional tax worthwhile, either by being infinitely scalable so that I could choose to invest more time in order to maximise output, or by offering a high enough wage in itself

The first side hustle I tried was sports umpiring. This fit my first criterion easily as games took place after work. I would arrive at a nearby venue with my whistle and scorekeeping app, then spend an hour or two sprinting up and down various South London sports halls trying to keep track and accurately administrate the play.

Although umpiring offered what I was looking for from a timing perspective, it didn’t meet my second or third criteria. It was much more difficult than I imagined it would be to see and mentally calculate gameplay in real time, even for the sports I knew well. For those I wasn’t so familiar with, it was even more challenging still. The pay was also minimum wage, which although higher in London, didn’t feel worth it for how stressed I felt at the end of each match.

The second side hustle I tried was freelance user research. Being freelance meant I could theoretically dedicate time to it on a schedule that suited me, it was something I knew well and could deliver value for my clients, and I set the pay so was able to calculate a rate that made sense for my goals.

Although this work certainly felt a better fit than umpiring, it eventually began occupying more space in my life and mind than I wanted. I found myself working late into the evenings and giving up numerous weekends, I felt annoyed when I received client emails outside of the times I’d committed to working with them and although the pay to output ratio was significantly more favourable than umpiring, I couldn’t simply leave the stress on the court and go home.

Finally, I found what’s since felt like the perfect solution – user research as a participant rather than a researcher via As a participant, I can choose when I have a free slot and would like to participate in a test. As I’m invariably talking about my own experiences with everyday issues, I’m rarely required to do any advance prep, which means the time spent logged into the test is contained and if a topic suggests it might take more from me than I want to give, I can simply decline that instance. The pay is usually around $60 an hour, but it’s infinitely scalable and the scaling is even compounded overtime by the number of positive reviews you receive as you participate in a greater number of studies.

Having tried three different side hustle options in 2022, user testing as a participant with has been the most successful by far and I’m looking forward to reviewing its contribution to my financial goals in the summer, once my first year of participation is complete!

Working out loud for lasting change

I’ve been thinking about this post for a while, as I realised it’s something I’ve really turned a corner on in the last few years of my career.

I’ve always been quite an introvert when it comes to my work, preferring the speed and focus that comes from designing, planning and executing product development with as few trusted colleagues and specialists as it takes to research, deliver and measure value for users as quickly and efficiently as possible.

However, a few years ago, as part of a mentoring session, I learned the mantra:

If you want to go fast, go alone. If you want to go far, go together.

This idea really stuck with me as I’d often found it difficult to communicate what I was working on and its importance as widely, frequently and collaboratively as I’ve since found to be vital for effective change.

The unintended consequence of my approach had often been that projects were deprioritised when I couldn’t successfully convey their value, or worse, had been duplicatively attempted by colleagues elsewhere in the organisation, unaware of my team’s isolated ambition to achieve the same outcome.

In the early stages of my career, I had been able to get away with this tendency as those above me played the leadership role I was neglecting to fill, but as I gained more experience myself, l became increasingly aware I had to step out of my comfort zone and embrace this skill if I was to make a meaningful impact in my role.

Since adopting this mantra in my day to day work, five lessons I have learned are:

  1. Every person I work with shares the same goal of wanting to deliver value to customers
  2. Working out loud from the very beginning drives the kind of analysis and perspective that is critical to true success
  3. Achievement is as much defined by the right conversations as it is by the end result
  4. Meaningful collaboration forms key relationships that allow more ambitious outcomes to be reached in future
  5. Shared ownership of success creates a culture of innovation that is necessary for long-term impact

At first, working out loud didn’t come as naturally to me as other aspects of product management. Now, it’s something I’m grateful to have realised and look forward to continuing to develop the skill!

Three surprising differences between the charity and private sector

Two years ago I made the decision to leave the charity sector and, due to Covid, I’ve actually managed to have three jobs in that time, so I thought I’d take the opportunity to reflect on my assumptions going in and share a few surprises I’ve found since making the change.

We value quantity over quality

The most surprising difference I’ve found is the tradeoffs in quality and best practice we are willing to make in order to increase our profits as quickly as possible. In the charity sector, we aim to do things cleanly and well, and we care less about how quickly value is returned for our efforts. We tend to be painfully diligent people, all too aware that our users are living with cancer, degenerative physical diseases or mental health problems and a good day in the office for us goes some way towards lightening that load for them.

In the private sector, however, the speed at which money is generated is the number one priority and we appear to be willing to sacrifice almost anything to get it. The consequence of this is the mounting of an endless and often prohibitive amount of technical debt. This is not only technical debt in the backend, for example in pipeline or service stability, but also in the frontend too. We worry little about bugs, broken UI, brand violations or fragmented user experiences. If a new feature will generate more money than fixing these issues, then that’s what we’ll work on, everything else is off the table until ‘quieter moments’, which of course never materialise.

We believe we deserve our jobs

Approach and attitude is another significant difference that continues to surprise me the more people I meet in the private sector. In charity, I always felt a sense that everyone around me believed they weren’t good enough and that even if they were, they were the luckiest people in the world to have that job and would work tirelessly to prove themselves and keep hold of it in the face of never-ending financial worry.

In the private sector, that sense appears reversed, people generally seem to feel the company they work for is lucky to have them and with that comes a strange sense of confident complacency that feels uncomfortable to me as someone coming in from a world dominated by anxious insecurity.

As a Product Manager, my job includes overseeing delivery and this is where I most notice the attitudinal disparity. If deadlines were threatened in the charity sector, people would be up all night, working at weekends or crying in private meetings with their managers, afraid that they were letting everybody down and would deserve to be fired as a result. Whilst in the private sector, deadlines often approach with a shrug as people casually state they didn’t achieve anything yesterday because they had to take their dog to the vet, it was already 5pm or they couldn’t see the value in the task.

There still isn’t enough money

One of the reasons I was initially interested in seeing what life was like on the other side of the fence was to see what could be achieved with much larger budgets. Working for a charity you become very creative, always looking for new ways to get around the fact that you can’t really afford to do what you need to. In the private sector I came in with the assumption that money would flow more freely and liberate teams to be bolder and more ambitious in their digital aspirations.

Instead, what I’ve largely experienced is a form of financial Parkinson’s Law in which premium capital leads to premium spending and what remains feels equally small and difficult to secure. This is particularly noticeable in recruitment where wages are vastly higher than in the charity sector and teams are comparatively very well staffed. This makes the case for additional resource and even the backfilling of existing roles surprisingly challenging.

And yet, I love it

Despite every surprising difference and every unusual challenge, I find it difficult to imagine going back to working in charity, at least for now.

Every day I come to work it’s interesting, fun and absolutely nobody is going to die.

Instead, the worst consequence of a bad day is a little lost revenue or a few disgruntled colleagues. I’m no longer fixated on the fact that what I do is too important for me to be doing it. Because it isn’t important, not really.

I like my work, I’m grateful to the tech industry for creating it and I take pride in what I do. But when I leave in the evening, I no longer lie awake at night wondering whether I did enough to alleviate the burden on someone living with stage four breast cancer or contemplating taking their own life.

Every time I lose a UX battle, a leadership debate or domain-impacting decision, I no longer torture myself with the potential implications for users whose lives are hard enough already. I can now finally afford not to place such heavy expectations on myself and those around me because, after ten years in digital, failing no longer feels to me like the end of the world.

Creating a digital breast cancer support course

Breast Cancer Now offers physical support courses to people living with primary and secondary breast cancer. One of these courses is Moving Forward, supporting people once they’ve finished treatment to cope with issues such as body confidence, returning to work and managing fear of recurrence.

As a charity, we can’t provide this free service to everyone we’d like to, we can’t run one in every part of the country, we can’t pay for people to travel up to 200 miles for their nearest service and we can’t offer much desired refreshers to previous attendants because it would take away a first time space from somebody else.

As a product manager, I was given the amazing opportunity to create a digital solution to these challenges with an online tool that would allow more people to access and work through the course material from home. It’s been one of the best projects I’ve worked on in this role, so I thought I’d share how it’s going so far!

First off I had research phase, I wanted to find out as much as I could about the needs of the course, the appetite for a digital version, feedback on the physical courses that I could factor into the development and I wanted to know more about what makes a successful online learning and support tool.

After that was a prototype phase, which allowed me to check the conclusions I was drawing in my mind were an accurate reflection of what the tool should be for users, course providers, content and health information specialists.

Then it was time to make an Alpha product which we could take ‘on the road’ to user groups around the country. This was the first time everyone had the chance to see what the tool could look like and how they might interact with it as a participant of a Moving Forward Online course. We’d got a lot of things right, people valued the usability, the content and the interactive nature of what we’d created, but the immense value the users provided as they participated in our workshops and feedback sessions was context.

As digital and health professionals, we were experts in how to technically make and deliver a valuable product, but most of us knew nothing about what it was like to participate as someone who had been through a breast cancer diagnosis. With insights from users with these direct experiences, we were able to identify what we hadn’t got right yet, which means by the time we create a Beta version of the tool for the New Year, we’ll know we’ll have created something that’s not only usable and informative, but also feels safe and empowering for everyone at home who’s been through the trauma of diagnosis and treatment and is looking to understand where to go from here.

The feedback sessions highlighted the importance of connection with others who are going through similar experiences, so we added a private and moderated group to the Breast Cancer Now Forum, which Moving Forward Online participants can connect to via single signon straight from the tool.

They also highlighted the importance of having a healthcare professional available as people worked through the material and worried about issues that might affect them, so we connected the tool to the Breast Cancer Now Helpline with a dynamic prompt, which means a phone icon displays when the Helpline is open, and an email icon displays overnight. That way users are always connected to the best way we can help them at the time they need it.

We knew managing fear of recurrence was what people reported to be most worried about when they came to the physical courses, so we’d made this the first section. But we hadn’t fully appreciated what an emotional trigger the topic would be for individuals participating in the course, so we reorganised the content and the language around this to much more sensitively and resourcefully guide people through valuable, informative and empowering modules and eventually towards issues around breast and body awareness after breast cancer.

After the Christmas holidays, we’ll deploy the sprint that includes these and many other new iterations of the tool, we’ll finalise the content, agree our evaluation strategy and be ready to launch a year long Beta with a select group of live users looking for support to Move Forward after breast cancer.

I’ve loved working on this project and while I’m leaving Breast Cancer Now in the New Year, I’m looking forward to checking in with the team on how the 2020 Beta goes!

Designing our way out of a microsite culture

When I first started as a product manager at Breast Cancer Care, I was aware that I had a limited window of impartiality, so I decided to use it to conduct a front-end audit of the site. I wanted to see what some of the main challenges of the role would be before I knew anything about our digital history or ways of working.

At the end of the audit, I’d examined every forgotten corner of the site, identified the areas I felt presented the biggest user experience challenges and created a list of seventy-six questions I wanted to spend the next few months gathering answers to, either internally or through user research.

A key challenge to solve

One of the biggest issues I noticed was our tendency to create microsites for every new campaign or fundraising activity. Internally this was taking a great deal more time than it needed to, and meaning quite small pieces of work were stealing the team’s attention for months at a time.

Externally I worried about the user experience implications of treating each activity as separate from the site as a whole, particularly as the microsites were so difficult to navigate to and from, and often contained a number of subsidiary pages that took users away from the actions we wanted them to complete.

Talking to people around the organisation, I realised a lot of this practice had developed because the site offered internal teams no good alternative. We didn’t have a sophisticated suite of content types to cater for the various ways we wanted to engage the outside world in our work, which left staff little choice but to begin almost entirely from scratch each time.

How we tackled the problem

To solve the problem we started working with the design agency William Joseph to create a new suite of content types, so that the site could better cater to user needs as well as our internal requirements. The first type we began working on was a flexible, modular and mobile-first campaign template, which is currently being used to showcase eleven of Breast Cancer Care’s key campaigns and fundraising activities.

Following the success of this approach, we set about creating a full suite of new and updated content types that are now in use across the site and better meet both the user and our internal fundraising, campaigns and information needs. These include types for:

The end result

Through this approach we’ve found an enormous reduction in the time and resource needed to create engaging content during key campaigns, activities and other peak periods.

We’ve been able to up-skill digital champions around the organisation to create more of their own content and reduce reliance on agencies to create landing pages on our behalf.

Brand-wise, the site has benefited from a vast improvement in standardisation and consistency, which proved difficult to achieve with so many agencies each interpreting our brand guidelines in slightly different ways.

Finally and most importantly, we’re now in the second year of using our new suite of content types and have seen a marked improvement in engagement and conversion to our key activities and campaigns.

If you’d like to see an example of a campaign page in action, you’re welcome to sign up for a Pink Ribbon Walk this summer. (See what I did there?)

This post was first published via Just Giving.

Learning that compromise doesn’t equal failure

I was on holiday in Africa this week, leaving product behind and heading for the mountains and the sun.

Whenever I’m away I tend to keep a sneaky eye on anything involving developers, because issues that arise there are usually the most complicated to fix, and I’m the one who knows what shade of yellow all the balls in the air are.

Mostly I decide things can wait, but occasionally I’ll step in if I see conversations heading towards a consequence that hasn’t been accounted for.

When that happened during my holiday this week, it made me wonder whether imperfection is inherent to product management and whether that might not just be a reassuring fact, but also a positive one that leads to better overall results.

Playing out on Podio this week I could see my team trying to fix something in a way I knew would break something else. They’d done all the right things; figured out the problem, consulted with a developer, kept people informed and agreed a fix.

When I jumped in and got them to revert their decision, it made me stop to notice that they were dealing with a problem that, in the timeframe, didn’t have a correct answer – there were two paths and the one I pushed them to take was still wrong, just less wrong than its alternative.

These are the types of decisions I make all the time, but on each occasion a tiny bit of me feels like a failure; I didn’t find the third way, I couldn’t get everybody to win before the clock ran out and I had to settle for something less than what I wanted.

Watching a great team of capable people going through the same process this week made me not only resolve to cut myself a little more slack in this area, but also gave me the opportunity to reflect on the benefits of that rock and hard place situation. There will be a third way for next time and getting back to work on Monday will allow me to find it, but will also give me something I wouldn’t have had if the issue had been easier to solve.

These trickier problems and craggier paths to success lead to the pondering, consulting and late night googling that make us good, better and then the best at our jobs. They’ve led us to find the third way more often than we’ve ever stopped to notice. The development is gradual, but the only way to achieve it is to keep clashing with the issues that don’t have an obvious answer and use what we learn to keep moving forward.

What I learned from five minutes with a user

General Assembly at the moment are running a series of free introductory seminars in various specialist areas. They’ve been great, I’d definitely recommend signing up to a couple if you have the time.

Last week I went to one on user experience design and I thought I’d share a highlight of the session.

Usually when a speaker says “I’d like you to get into pairs” I get an internal sense of dismay. After all, if I relished opportunities to make awkward chat with humans I didn’t know, I wouldn’t be working in digital.

However, what I have realised over the last five years is how much I love user research, and fortunately that was the task we were set in this session.

We had five minutes to imagine we were working on improving the Citymapper app and run user testing with the person next to us about their experience of using it, in order to make informed recommendations about what could be improved.

The most interesting challenge with my partner, I’ll call him Adam, was that he was very distrustful of apps generally, particularly apps that asked for access to his location. He felt ill-informed about how his data might be used, and uncertain about the location-driven apps he downloaded having access to other areas of his phone.

Adam had never used a travel app, when I asked him about the methods he preferred for navigating London, he said he would use the TFL website. This started as a productive line of enquiry as we went through the way he used the site, but it soon became clear that he didn’t have very high expectations of TFL, it was simply ‘fine.’

Fine was enough for Adam when it came to maintaining his digital privacy. When I asked him how he would get around outside of London, he said he would ask for directions or take a printed map of his journey – that was how strongly he felt about protecting his identity online.

Thinking about the app design brief, I wanted to get to more than ‘fine’ with Adam, I wanted to know what would make a digital experience great for him. So I started asking him about his favourite non location based app.

It took him no time to get out his phone and show me a radio product he loved, and the most interesting thing about this was how much of what he said could be applied to the development of the Citymapper app.

On the radio app’s home screen, there were six content categories – things like ‘popular now’ ‘stations’ and ‘favourites.’ Though the ‘favourites’ option was in the bottom left corner, not the usual position of popular actions, Adam went straight to it and started showing me around. This indicated how important personalisation was to him, something really useful to explore with users in the context of the Citymapper app.

I then asked him to show me how I might use it as a first-time user, to get an idea of the journey he might have been on when he first signed up, and what he liked about that.

He showed me the search function and commented on how good the app was at returning exactly what he was looking for really quickly – another useful insight for apps more generally. The interesting thing about that search function was how it remembered his latest query and then made suggestions on what his next one might be.

He said he found this feature surprisingly accurate and  that it had introduced him to new stations he wouldn’t previously have come across. It was clear from this that he had begun to trust the app and let it guide his behaviour and propensity to try new things – another great example of something that could be explored more generally in the development of other platforms.

The whole task was a great reminder that good digital experiences come from putting the person before the product. To learn these things in five minutes made me really excited about some user testing I’m running for Breast Cancer Care next week. If you haven’t done any for a while, I hope this can be some inspiration!

Adopting a ‘start where you are’ approach to digital

A few months ago, I went to one of the really great (and free!) digital seminars run by Precedent Communications.

The main takeaway for digital progress in an organisation was to “start where you are”, which was interesting for me as one of the things I was working on at the time was creating a tool for the site which would allow all supporters to share examples of having challenged mental health stigma in their community, school, workplace or daily life.

As the needs of each group were so similar, I was keen to find a way to unite them into one resource that would work for everyone both internally and externally, without any UX compromises that would undermine the value and potential of the tool.

At the same time, I was aware of the need to view the tool’s creation in the context of other interactive areas of the site, to ensure we weren’t reinventing the wheel and dividing supporter attention between similar actions.

In ascertaining requirements, both internally and among key supporter groups who had initially expressed a need for the tool, I identified a significant functionality overlap between this project and something we had previously produced to support our national campaign drive in 2015. The campaigns team had been keen to find a way to ensure this bit of the site remained relevant beyond the campaign, so to my mind, this was a perfect opportunity to test out the “start where you are” philosophy.

Adopting this approach saved us a lot of time and money; we were able to get the tool built easily within our usual monthly sprint turnaround, and for just over £1,000. Most importantly, we were deploying to live having already worked out any UX kinks from the previous iteration, giving us a valuable product from the outset that supporters immediately began to take advantage of.

I’ll definitely be incorporating this into my thinking again!