Back to resources

Implementing a New Product From the Scratch

Architecture
Customers
Product
Agile / Scrum

9 December, 2021

Jan Pieczykolan
Jan Pieczykolan

Head of IT Development at Santander Bank Polska

Jan Pieczykolan, Software Engineering Director, describes how he successfully started a new product.

Problem

The company won a tender which was to provide a software solution. Compared to the whole tender, the software part was small, and its description in the tender documentation was minimal – only a list of modules with a one-line description of each of them. But, in reality, it was a fully functional software stack for a medium telecommunication operator. It consisted of modules like billing, CRM, self-care, admin panel, and several others.

What made this initiative even more difficult was that one of the goals of the tender was to establish a legal entity that would run the whole infrastructure and deliver software. We wanted to use the opportunity to build a new product. However, the problem was a lack of requirements and analysis. Therefore, there were no business users to ask for their needs.

We started by gathering our knowledge about major business processes run by telecommunication operators. We identified usual issues that our customers face in their IT environments, which led us to additional assumptions and non-functional requirements. We proposed an initial architecture of our new product based on that, and we stuck. We had a comprehensive high-level design based on real-life processes, but we missed a starting point for developers. Something from which they could start and then keep building upon it.

Actions taken

We agreed to start with the Scrum process as it was a good idea to keep up the delivery discipline. In such initiatives – in which there are no customers and nobody checks the progress, we tend to spend more time on things that are not necessary. Thanks to time boxing, the Scrum process requires the team to deliver from sprint 0, which helps them focus on the most important things first.

We asked an external consultant to prepare a Scrum workshop for the whole team. To assure that we all understand it in the same way and agree on how we are going to work on this specific project. This was an important action as all of us had some experience from the past, but usually, people understand Scrum differently; therefore, such unification is a good idea to avoid misunderstanding in the middle of the project. Also, engaging an external person turned out to be a perfect move as he brought a broad experience gathered from many customers he was providing consultancy services.

Also, we found a product owner that took the responsibility of filling up our backlog. Lack of business verification of our ideas was difficult, but we had to start from something as the deadline was getting closer. Therefore, we used our experience to start writing down stories, and this helped because shortly, we began to see living applications instead of abstract architecture and processes.

Lessons learned

  • Prepare a solid foundation on which you will be building your applications – an architecture. A clear one will guide you through the whole implementation process, and you won't be stuck in a dead-end street. This should happen before you start the implementation process as an architecture may imply what development tools and technologies you should use.
  • Don't forget to document project decisions – write down your concerns and assumptions to avoid reinventing the wheel when something similar appears (you will be able to refer to your decisions and considerations from the past).
  • Don't be afraid of changes – eventually, you will be asked for customizations and plan possibilities to develop them at an early stage.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

How Product Management Chose Me

23 June

My accidental journey into product management

Product
Personal Growth
New PM
Career Path
Michael Castro

Michael Castro

Sr. Manager, Product Management at Capital One

How Product Marketing Can (and Should) Help Product Development

20 June

Pavel Safarik, Head of Product at ROI Hunter, discusses the frequently overlooked role of product marketing in getting high user adoption rates for your product.

Goal Setting
Product Team
Product
Different Skillsets
Cross-Functional Collaboration
Pavel Safarik

Pavel Safarik

Head of Product at ROI Hunter

How to Successfully Rebuild Your Product

6 June

Adir Nashawi, Senior Product Manager at Hibob, shares his insight and experience from rebuilding a product to handle many feature requests and offerings.

Customers
Product
Dev Processes
Users
Prioritization
Adir Nashawi

Adir Nashawi

Senior Product Manager at Hibob

How to Empower Teams to Build Out a Product Portfolio During Company Growth

6 June

Ivo Minjauw, Global Product Director at OTA Insight, discusses the importance of structuring your teams when undergoing company growth.

Alignment
Goal Setting
Product
Ownership
Performance
Ivo Minjauw

Ivo Minjauw

Global Product Director at OTA Insight

Finding the Mission-Driven Product Management Role That You Want

5 June

Krishanu Sengupta, Product Lead, AI & ML at Compass, offers insight on how to develop into a role you are passionate about by obtaining experience in roles that build relevant skills.

Goal Setting
Managing Expectations
Product
Personal Growth
Motivation
Career Path
Krishanu Sengupta

Krishanu Sengupta

Product Lead, AI & ML at Compass

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.