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

Scaling a Team in Two Parts: The Product and Manager

2 August

Viswa Mani Kiran Peddinti, Sr Engineering Manager at Instacart, walks through his experience scaling a team, product and his skills as a leader.

Managing Expectations
Product
Scaling Team
Leadership
Meetings
Viswa Mani Kiran Peddinti

Viswa Mani Kiran Peddinti

Sr Engineering Manager at Instacart

(Re)Organizing Your Teams Using Domain-Driven Design

12 July

A proposal for how to create an org structure that will deliver software systems that you want, not ones you get stuck with.

Alignment
Architecture
Scaling Team
Building A Team
Internal Communication
Reorganization
Ram Singh

Ram Singh

CTO at REAL Engagement & Loyalty

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