Envato Elements is a design subscription service. It includes top quality content from across our marketplaces, now, including photos! Here’s what we learned while launching our new photo library, from the perspective of a product manager:
Lesson 1: Big bang product launches can go bang. Avoid them if you can.

For the sake of time I won’t go into the reasons why, but, the situation dictated a big bang launch. All or nothing.
The photos project had been running for over a year at Envato. Multiple teams across multiple departments have been devising a strategy, curating a photo library, building tech and formulating a marketing plan destined for millions of people.
To add fuel to that fire, the photos project was built on a brand spanking new tech stack*. It hadn’t experienced any load, let alone the hundreds of thousands of people that were about to trample all over it.
I’d been in the team for a month and I was tasked with co-managing the launch of Photos with my Development Manager, Lindsay. I was, figuratively, crapping myself.
But, I had (and still have) a great partner in crime with Lindsay. He, also figuratively crapping himself, suggested that in lieu of an MVP approach, we could release incrementally.
Our first release was to the ~300 staff at Envato. Our main objective was to watch the tech stack, looking for any signs that it might fall over. It didn’t! We also found that people from all over the company had become emotionally connected to our product. When they were given early access and asked for their opinions, it made them feel like they were a part of it. People from all over the business truly wanted our project to succeed and went out of their way to help make that happen.
Then we released to 5% of users, then a day later we went to 20%, then… we found a problem! A serious problem. I won’t go into the specifics, but, if we didn’t find it there and then, there was a good chance that the entire site could have gone down. It was an easy fix, but an incredibly important one.
Once that was sorted out, we steadied our nerves and went to 50%. Then, just over a week after our first internal release, we took a deep breath and we went for it.
SUCCESS!
Through this I learned that where possible, you should segment your product, minimum viable product style. Where you can’t, you should segment your release, Brett and Lindsay style**.
*Not sure what a ‘tech stack’ is? Skip to the end for a tech-jargon cheatsheet.
**Incremental releases are a standard approach. It was not invented by myself nor Lindsay. It has never before and in all probability will never again will be referred to as “Brett and Lindsay Style”. You may be laughed at if you use that term in public.
Lesson 2: Listen.

From this I was humbly reminded to listen to our users. Research, research, research. And to focus on understanding and solving the problems that really matter, first.
Lesson 3: Measure to move.

Understanding what you want to achieve from a project right from the start is fundamental. It helps shape the business case. But, it’s integral that we don’t stop thinking about success metrics there.
In agile software delivery, we learn about the product as we’re building it and we feed that understanding back into the design.
As a project is built, it evolves.
We craft each user interaction with the intention of increasing overall conversion and retention. As these interactions are fleshed out during the build, we make assumptions as to how these interactions will perform. Measuring the success of these interactions takes us from assuming what choices led to overall success, to knowing. It gives us the power to iterate with confidence.
When I arrived on the team, the requirements detailing the data to be recorded were long since finalised. They included churn, the number of subscribers downloading photos, etc. It didn’t, however, capture recording the interactions mentioned above. And I, madly focused on on executing the plan, didn’t think to adapt the plan.
I’m now working with our Analytics teams to retrofit capturing some key metrics. It would have been easier to bake these in prior to launch, and I would already have a month’s worth of data.
From this I learned two main things:
- Don’t join a team one month away from shipping a huge project (that one was a joke).
- Plans are meant to be written in pencil. Not pen. Respond to change over following a plan.
Lesson 4: Photo buyers do come to buy photos, but they also come to be inspired.

When I first joined the team I spent a lot of time looking at competitors. I remember being shocked that it wasn’t uncommon to find sub par photos on other stock photo sites being sold for upwards of $50 with conditional licensing! That’s a lot of pressure to get it right on the first go.
This understanding has shaped the design of subsequent features and iterations. Not everyone knows exactly what photo they want when they start looking. Often, they have no idea at all. They’re looking for us to help them. They’re looking for inspiration.
This was a healthy reminder to identify and challenge assumptions. No matter how long held and solid they look, assumptions need to be called out, and, where possible, tested.
