At a former company, I worked to launch an e-commerce platform to help the business scale while utilizing our current skillsets in uncovering sales intelligence and creating account profiles.
I played a key role in brainstorming and strategizing on ideas to develop the platform, everything from conducting user research and competitive and market analysis to working with an agile team on design and development.
In the interest of time, I won’t be reviewing every phase of the e-commerce platform launch here. Instead, I’d like to showcase my knowledge and background with the design and build stages. But first, let’s begin with my role in understanding this new platform’s position in the market.
In the early stages, I conducted market analysis with a bottom-up approach to think about the current sales of similar products and estimate how much of their customer base and sales we could capture.
In researching the competitor landscape, I found that many companies could not be considered as direct competitors to the platform we were proposing because their solutions were not going after the same customer group AND solving the same problem. Some companies who share our customer base were offering appointment setting, while others who hosted account information were more focused on stakeholders and contact information.
I did find one or two offerings which I felt could be considered direct competitors as their solutions similarly offered sales prep data, available contacts, and industry information – selling to our customer base and looking to solve the same problem: cutting time on the account research needed to reveal potential sales opportunities.
The bottom-up approach I took allowed for a conservative estimation but was ultimately a positive result. We believed by capturing 3% of select competitors’ sales, we could gain an entirely new revenue stream that was 20% greater than our average annual figure.
Other research and analysis we conducted included developing feature tables to compare our proposed e-commerce platform to our competitors’ products on a series of dimensions to understand how competitive it could be. Using free resources like G2, we found opportunities for differentiation and weaknesses to exploit – mostly around actionability and reliability of content.
I also worked with the CEO to further develop our understanding of the potential user base and seek quantifiable interest from customers with the use of MVP experiments. To get a glimpse into my experience with user research and MVP strategies, please check out my work on the Quickstart launch.
So, with the competitor and market analysis, feature triage, user research, and MVP testing under my belt, the company was ready to achieve the vision. I began discussing ideas with a Designer/Developer who had done work with us on brand development – a great resource and guide that helped me optimize the process of developing a wireframe, mockup, and prototype for what the platform would look like.
The results of the design phase are recreated below.
First, I took a stab at some wireframes – everything from the home page to viewing and searching for all account profiles, to the actual account profile page and purchase experience.
The key things in creating these was to ask what the purpose was of each page and what functions should be achievable on each one. Working with the designer to create as many iterations as possible, we eventually were able to land on a set of wireframes that captured a version of the journey. I’m including a few of the wireframes here for reference.
The low-fidelity wireframes while helping create the full experience of the platform, forced us to focus on functionality instead of getting lost in the detail and allowed us to rapidly iterate during user testing.
They also allowed us to easily incorporate new directives from the CEO such as including new purchase options to enable more flexibility for customers.
Since we did not have the budget to engage in broad user testing, we gathered several employees including our inside sales team members and researchers to receive feedback on the user interface – The unfinished design enabled fruitful conversations and allowed us to better map the journey through the content.
During the testing and feedback sessions, I really wanted folks to focus on the problems we were trying to solve with the e-commerce platform and determine if users felt that it was achieving that. For example, does the product save an individual’s time by letting them easily find and uncover intelligence around their target accounts – so is the platform intuitive, is it understood what the platform offers, and can account profiles easily be previewed, purchased, and revisited.
Walking through the wireframe with the team, we uncovered several areas that could be optimized, and I’ve reproduced some of these points here:
These were just some of the platform journey items that we addressed during user testing. After a couple rounds of iteration, I worked with the Designer and got hands-on experience creating high fidelity mockups and a prototype using InVision. If you’d like to take a peek at these and interact with the prototype, please connect with me and I’d be happy to send over a shareable link.
Once we landed on a high-fidelity prototype, it was time to work with a third-party development team with whom the CEO and I coordinated very closely. I should note here that it’s always beneficial to have the development team building your product in on the roadmapping and design stages but unfortunately, we did not have that liberty due to budget constraints.
Working with a hired development team, I was fortunate enough to be exposed to and play a part in the product development stage – everything from working on epic spec sheets and creating user stories to understanding team velocity and technical design tradeoffs – key aspects of a product management role.
During this phase my role was focused on clearly communicating the features we were looking to include on the platform, particularly on the backend where our company’s teams would be working out of day in and day out.
To give you some insight into my knowledge around these facets of product development, I’m sharing an example of an epic and its constituent user stories for a ‘feature’ of the platform that is back-end facing (for the teams who would be maintaining content on the e-commerce site). I recreated the epic spec sheet and user stories on JIRA for sample purposes to demonstrate my knowledge of the project management software.
I haven’t included the Designer and Engineer Requirements here as the development team took charge of these sections of the epic spec sheet, so I rather not butcher them here.
Meeting with the team multiple times a week, I leveraged user stories to explain to developers what the features we proposed need to do without telling them how to do it. In other words, I became adept at suggesting ‘what’ we want and the ‘why’ we want it but let the experts determine how to do it. Additionally, I played a key role in establishing acceptance criteria as my colleagues and I were the intended users and of course the point of this step was to communicate clear conditions that need to be met to consider a user story complete.
During these discussions, we also touched on the estimation of value to cost ratios to determine if proposed features and functionalities are worth the time and money to build at least for the MVP.
This communication helped prioritize what was built for the initial launch as well as estimate the velocity at which sprints could be completed.
Here is an example of a user story and the acceptance criteria:
Now, this user story was part and parcel of the epic I laid out above and lived in the backlog as a ticket with other user stories, tasks, and bugs.
As I mentioned, before a sprint during the planning sessions, the development team and company stakeholders would get together to discuss the priority and difficulty of various tickets, each one measured by a particular method – the former by the MoSCoW method and the latter by a story point system.
With the MoSCoW method, we were able to determine what ‘features’ or tickets were must-haves, should-haves, and could-haves and assigned them high, medium, and low priorities. We didn’t bother with the won’t haves.
The point system was also very helpful, particularly for the Tech Lead to decide which tickets should and could be included in the next sprint. The team was familiar with each other and had a good grasp estimating their own velocity. During these meetups, developers would be asked to throw a number using their hand from 1-5 which would determine the difficulty of each prioritized ticket.
Together the MoSCoW method and the story point system enabled my team and the development team to determine the prioritized ‘list of things’ we wanted to complete in a two-week sprint.
Being as involved as I was with the build stage, talking to engineers, and discussing technical tradeoffs, I gained a wealth of experience around product management while also learning how exciting and rewarding it was to be at the center of a platform product launch.
In this final sum up, I’d like to touch on some next steps I would consider as a product owner for the platform.
First thing I’d do is recall our goal for the project which was to scale the business and produce a new revenue stream that we could eventually be the primary source of income. To reach that goal, we would first need to focus on adoption.
An easy place to start would be to measure marketing’s launch effort. With the use of landing page experiments, we can track the effectiveness of marketing channels and different tactics. Maybe we could set up a landing page for each unique channel or campaign to make it simpler to determine where traffic is coming from and identify how visitors are progressing through or dropping out of the sales funnel.
At this early stage of the platform launch, user growth and engagement metrics are key. I would be interested in website visitors (both new and returning) as well as core user actions – like the number of users who are using the search feature, clicking the preview button on the search/results page, and creating an account. Of course, none of these actions will directly result in revenue for the business, but if website traffic shows them occurring consistently then it’s a good indication of content adoption.
And since the platform is an e-commerce site, there are a number of other metrics that we could consider as well, such as conversion rate or shopping cart abandonment rate, but what’s essential here – particularly in this beginning phase of the platform’s launch – is not to get buried and overwhelmed with metrics. Understanding context and discussing near-term and long-term goals with leadership can help narrow down what’s most important for the business at a particular time and place of the product’s lifecycle.
My experience with the build phase of an e-commerce platform launch was extremely valuable in driving my understanding for technology product development. It also put me in a position to work with a cross-functional team, prepare competitive and market analysis, learn and apply key product design and development methodologies, and choose the right metrics to achieve a product vision. Most importantly, I believe this experience ignited a real passion for product development and set me on a path to become a great product manager.
