The extended team model could be the best tactic to get your startup into the market or drive your business ahead of the competition. Using the extended team model can help you grow your capabilities without eating your margin. And it is the best way to respond quickly to market changes and moves by the competition. Let’s dive into the details behind the Extended Team Model.
What is the Extended Team Model?
The Extended Team Model is an organisational structure where the core team that provides deep institutional and product knowledge is based in-house and works closely with one or more developers who work remotely.
The size of an extended team, and here we are talking mainly about extended software development teams, depends on the needs of the business.
A startup might have a core team of a single Product Manager and the entire development team is an extended team. A corporate business unit might need expertise they can’t access in-house. A business with an established online presence might need some regular devops hours to keep their website and backend working smoothly.
The extended team model lets businesses scale their hiring to exactly match their needs. As extended software development teams are assembled out of a single provider’s talent pool, that hiring can happen quickly – sometimes in days, often not longer than two weeks, rather than the months it can take to attract, vet, and interview team members with the normal hiring process.
How is the Extended Team Model different from Outsourcing?
The big differences between the extended team model and outsourcing are control and integration.
Outsourcing works like a black box. You feed in specifications and you get code or product out. There are deliverables and meetings, but you have zero insight into who is doing the coding, how focused they are on your particular project or even their level of expertise.
With the extended team model you are involved in team selection. You know who will be part of your extended team and you will know, either through testing or interviews, their ability level.
Your extended team members, if they are full time, will be devoted only to your project. Unlike an outsourced developer that you will never contact directly, extended development team members are integrated into your team. They participate in scrums, they work directly on your codebase using the same tools as the rest of your team. Your goals are their goals.
How is the Extended Team Model different from a remote team?
The extended team model differs from a remote team by being more consistent, more flexible and more reliable.
Here the key feature of an extended team is that every extended team member is part of the same talent pool. They come from a single extended team member provider, such as SoftwareSeni. This means they share the same work culture, have the same training (though they may be at different levels of expertise), and have access to the same resources, including dedicated HR and support. And for your business, this means you have a single point of contact to deal with for upsizing and downsizing your extended team, swapping in new skillsets and so on.
The members of a remote team won’t have this additional layer of management. You will be managing each remote team member directly with no insight into their working conditions, work habits or day-to-day productivity.
A remote team will also have to be assembled by going through the same slow hiring process as an in-house team, instead of the rapid selection process used with an extended team provider.
Why use the extended team model?
The extended team model has a number of advantages, some already discussed above. Speed of hiring is a big one this article keeps mentioning. Another is availability of expertise. Depending upon your location, certain skill sets might be beyond your budget or simply unavailable. Your product vision or business model might not survive these limitations.
So, being able to assemble a team with the requisite skills out of the talent pool of an extended team member provider can be the difference between success or failure.
The extended team model allows you to grow headcount without growing your footprint. All resources your extended team members need are provided by the extended team provider – computers, desks, office space.
Another key feature that makes using the extended team model so powerful is the flexibility to grow and shrink your team based on your exact needs in the moment, or to swap out extended developers for different skill sets as you move through different stages of product development.
When to use the extended team model?
Businesses should use the extended team model when they have a clear and detailed vision of what they want to achieve but are facing constraints across time, funding, talent or space.
That kind of covers just about every business, doesn’t it?
Prior experience in managing developers or projects and exposure to strategies for working with remote team members (almost universal now in 2023) are the two biggest requirements for using the extended team model.
If you don’t have this in-house experience you might want to take a second look at out-sourcing or hiring a software development agency like SoftwareSeni directly.
How to use the extended team model
Working with an extended team is not much different from working with a mixed in-house/remote team. You face the same challenges of integrating staff into your processes and work culture, and the overhead that comes with suddenly having a higher headcount. It is not core team vs extended team, it’s core team + extended team.
As an extended team provider we have some experience in this matter. We have an article on the simple secrets to making your extended team work, and of course we are focused on helping our extended team clients succeed and are always available for guidance, support and coaching.
Where to hire an extended team?
Right here. SoftwareSeni is Sydney-based and our main focus is offering extended team services to Australian startups and businesses that think like startups.
This focus is why our talent pool is based in Indonesia. It provides an extensive time zone overlap with Australia that we find makes working with extended development teams so much more effective, both in terms of quality of communication and responsiveness.
Our team of developers (as well as design, UX, devops, and customer service) is based in Yogyakarta. The city is a major learning centre with a large, well-established tech culture. This has allowed us to pick and choose our team members to build the deep expertise that will benefit any project.
We can provide expertise at scales from a part-time single developer up to a team of dozens and for any stage of product development, from ideation to maintenance mode.
If you’re outside of Australia and have strong remote team management capabilities, you might still find the quality and range of our tech talent worth the larger time zone difference.
So if you’re looking to increase your headcount and are searching out tech talent to deliver the outcomes your business needs, get in touch.
Making it real – the software development process behind your app
This article is going to go into details on the software development process at SoftwareSeni. The target audience is our clients and potential clients. If you’re thinking about getting an app or a site built some day, then you will find it interesting to understand how these processes are run.
The article is a follow on from similar articles on product conception, prototyping, and business rules.
With all the above completed, the software development can now start. If you’re curious about the cost of software development, we recommend reading our article on Fixed Price Contract vs Agile Development.
SoftwareSeni is an Agile house. Software development under Agile has a definite beginning, but it doesn’t really have a middle or an end. This is due to the iterative nature of Agile development. One of the early iterations will see the launch of your product. But once it is live each iteration after that will be launching new features and capabilities.
The beginning of the software development process
At SoftwareSeni we divide the beginning into two phases: Preparation and Kick-off.
In the Preparation phase we take the wireframes and business rules and use them to create the product backlog.
The product backlog is an Agile thing. It is the single source for everything that the dev team needs to work on. So it includes the features of your app that need to be implemented, but it will also contain bug fixes, setting up hosting infrastructure and any changes it needs — anything and everything the dev team needs to complete your app and keep it running.
Using the product backlog, work is prioritised based on impact and effort. The business rules you documented earlier are broken down into epics. The epics are broken down into stories and those are finally broken down into tasks. All of these go into the product backlog.
Because the product backlog is used to prioritise work it is not a static list. Everything that needs to be done gets added to the backlog as it pops up. This requires the product backlog to be regularly updated and re-prioritised. This is part of the Agile process.
Along with the product backlog, the preparation phase involves:
- a sprint plan
- the confirmed timeline and milestones
- a demo plan (both internal and for you)
- establishing development environments (typically separate Dev, Staging and Production systems)
- a QA Strategy and Plan that covers automation, test plans, test scripts, test data, and resource planning.
- a User Acceptance Testing (UAT) plan covering the application security checklist and penetration testing
Kick-off
The kick-off for your project is carried out in two meetings. For you, it’s a briefing where we communicate how the software development will proceed and we all confirm we are in agreement on project goals, deliverables and timelines.
The team runs through the same information in their own meeting. This is also the point where the final structure of the team — headcount and skillset — is settled.
After this, the development begins.
The Agile development of your product
Agile operates as a series of sprints. Don’t imagine a roomful of people pounding at keyboards. Programming is a slow and thoughtful process. Agile packages that process into short, often two week long, periods of focus: the sprint.
If you’re new to Agile you might want to read Agile basics for small businesses and start-ups.
The first series of sprints are focused on getting your MVP in front of customers. Once your app or site is live subsequent iterations make it easy to adapt focus and schedules based on app usage and revealed needs.
A sprint is divided up into multiple stages that can be summarised as:
- planning what to work on
- doing the work
- reviewing the work
The result is a two-weekly cycle that runs like this:
Keeping you in the loop
The beauty of Agile is the regular feedback on progress that is available. You will have opportunities to review work to date and current progress at multiple stages through the project. This will be via weekly or fortnightly Work In Progress (WIP) meetings. This is on top of the weekly reports and updates that we send you.
These meetings are essential to ensure your vision of the app is being correctly interpreted by the team. This might sound surprising, but every product is the sum of thousands of tiny decisions. Being involved in the process, supplying clear and concise feedback, ensures your vision is fulfilled as efficiently as possible.
Development never runs issue-free. There are always issues related to usability or functionality that could not be foreseen from wireframes and business rules alone. These are the kinds of things that more documentation can’t fix. They can only be discovered during the building and testing.
But this is exactly what the Agile process is designed to cope with. Any issues revealed get added to the product backlog and prioritised and the project keeps moving forward.
Sometimes these issues will impact product scope or your preferred timeline. Agile lets us catch these early and our regular reporting to you ensures you have time to act quickly on them.
Demo day
As you know, software development is often divided between front end — the UI and UX your customers will interact with, and back end — all the code that interfaces with your business, talks to databases, handles logins, etc.
Once the sprints covering both facets of your app reach a mature enough state fortnightly demos begin. These are yet another opportunity to keep development aligned with your vision, to spot any issues and to just enjoy seeing your product coming to life. It’s an exciting part of the process.
Rushing towards launch
Once the demo days start you are closing in on the launch of your MVP. While you are preparing your marketing push for the big day, the SoftwareSeni team is running QA on your app, hunting down and squashing bugs. They are also preparing for the User Acceptance Testing (UAT) to ensure that your app, and your users, will be secure.
The first launch is just the beginning. It’s definitely memorable, but you will be launching a new version with new features and new fixes every two weeks as your user base grows and your product’s functionality grows with them. This process will become part of your business’s day-to-day workflow.
The new normal
The Silicon Valley phrase is “Software is eating the world”. Once your product is live, whatever your business is, it is now in part a software business. And as long as you’re in business, SoftwareSeni will be there to help you with insight, strategy, tech talent, and raw people power.
If you’re ready to transform your business into a software business with an app or website, get in contact and let’s get the process started.
If you’re new to the process, we recommend starting with our article on product conception – bringing your business idea to life.
Fixed price contract vs Agile for product development
Software is expensive to build. Throwing around the kind of money it costs to build a new product — whether it’s an app or web site — should make you nervous.
And if you’re not familiar with software development, starting down the product path might feel like you’re rolling the dice and hoping for an eleven.
If that captures how you feel, then this article is here to show you that you do have control. Success is never guaranteed, but there are processes and strategies that enable you to move systematically towards the best outcome. Any decent development partner will have these in place.
“Insert cash, get app” is the wrong model
Commissioning a new product is not a transaction. It’s the start of (cue cliché) a journey. It’s going to change your business. You’ll need to onboard new responsibilities. You might need to create new roles.
The first step in taking control is to look at your future product as an investment in a long term process. This opens up opportunities to move your product forward based on new cash flows it will bring in. Which brings us to the biggest decision you’re going to make, and one that our team at SoftwareSeni has strong opinions on.
Fixed price vs Agile
Some people will not give up the “Insert cash, get app” model. This model’s real name is “Fixed price contract” and it drags software development back to the 70s when the Waterfall Methodology was the only option.
Don’t go commissioning waterfalls
For a fixed price contract to avoid cost overruns you need to first scope and price every single thing that needs to be done. This feat of excessive documentation is the start of the Waterfall Methodology. It’s followed by first doing A as described in the documentation, then B, and years later you might be up to L. Forget about Z.
No matter how much documentation is done, scoping and defining a complex project in advance will never get everything right. Issues, oversights, and moving targets will only show up once the project is underway. This inevitability requires budgets to be drawn up that will cover contingency costs. These can increase the final cost by anywhere from 20% to 100%.
That’s right. Your software developer, even SoftwareSeni, will add 20% to 100% to a fixed price contract to protect themselves. And you. You don’t want your software developer going out of business just before your product is finished, do you?
It gets worse. Creating all that documentation delays the start of development. Then there are more delays as developers meet the documentation for the first time and try to understand it. This is slow. It gives the project plenty of time to shift out of sync with the business and the market.
Changing course, which will happen for the reasons given above, requires making changes to the fixed cost plan. Which means more documentation and more time and more billable hours taken to price out the cost variations to catch up with the status quo. And another 20% – 100% on top. It’s a lot of money and none of it is being used to add value for the customers.
Move quickly, be Agile
At SoftwareSeni we find our clients get the best outcomes using an Agile methodology. If this is all new to you we suggest you read this quick introduction on Agile. When using the Agile methodology product development starts with a high level estimate based on an hourly rate.
The high level estimate
To arrive at a high level estimate, at SoftwareSeni we go through an initial review of the product with you. We look at proposed functionality, third party services it will interface with (such as payments, authentication, booking and inventory systems, CRM, etc), admin requirements, and more.
Out of this we can provide you with an initial estimated price range. It can be a wide range, with a 50% spread or even more. That’s why the next step is to tighten that range, but at this point it’s your first opportunity to commit to the project or delay it.
Narrowing the range
The next step is the scoping stage. Even with Agile you cannot escape some documentation. But in Agile we document to understand rather than to determine implementation.
In the scoping stage we work to capture all the key items the product needs. Depending on the complexity of the product this can cost $5k-$15k.
Take something universal like user accounts. How are users going to log in? Will social logins be allowed? Email and password? Both? Decisions like this will have design and technical impacts.
From feature decisions like this we build a high level overview of the product and the project to build it.
The output from this stage is a set of wireframes. They look like cartoon versions of the product, but they document visually the features of the product and how they will interact. They are really a visual documentation of the requirements. They are much easier to understand and to grasp than a shelf of ring-binders full of written documentation.
From the features documented in the wireframes a tighter estimate is derived. Now comes the time where you decide how to allocate your budget.
Strategising your spend
With a more detailed estimate that breaks out the key costs, you can make decisions on which features to start with and which features to delay.
Under Agile and Lean Business methodology, these decisions are best made by focusing on achieving product-market fit. How do you know you have product-market fit? Users spend money on your product.
How do you get there? Iteration.
Iterate to focus your spend
Following Agile and Lean Business, you’re going to hit the market with an MVP — a Minimal Viable Product. This is the product that requires the least time and money to build but still delivers value to the users.
How do you know it delivers value before launch? You will have run user tests with your wireframes, or invested in a clickable prototype based on those wireframes. You won’t be launching blind into the marketplace.
But the market might not match your expectations. In fact, it probably won’t. But because you’re following Agile, you’re prepared for this. You watch the response to your launch and plan your next iteration.
That next iteration will be a new version of your product. Because you’re following Agile, it will go live in 2 to 4 weeks. It might have new features. It might be a tweak of the design. You will get more useful feedback to use in the next iteration.
By working with your development team you can direct your spend for each iteration, targeting resources at the areas that will deliver the highest returns.
If you do it right, if you find that product-market fit, revenue generated by your product will enable it to become self-supporting and fund its own subsequent iterations before you have burned through the initial estimate.
How do you know you’re finished?
After several iterations you will come to realise one of the truths about software based products — they are never finished.
You might stop adding features, but your product runs within, and is powered by, a complex network of services, code libraries, programming languages and technical standards. There is no escaping your product’s dependence on these. When they change, and they do, your product may need to be updated in order to keep working.
Keeping your product working, as well as keeping it available via hosting and monitoring, is an ongoing cost. When you include the costs of third party integrations, it may cost as much as 20% of your initial development budget per year to keep your product alive.
Agile for the win
The costs outlined above are the final reason why launching with an MVP and iterating as fast as you can to generate revenue, the Agile methodology, brings better outcomes than the Waterfall methodology aka Fixed Price Contract.
There is one place where a fixed price contract makes sense, but why would you want to go there? That place is when a category of product or app or web site is so well-established and well understood that there are white label solutions available. Those markets exist and they are saturated. Why launch into one of those?
Given that caveat, we would always advise you to choose the control, flexibility, and velocity of Agile methodology and pricing over fixed price contracts. Leave those to the businesses breaking into overcrowded markets, while you launch your new product into a market that’s still wide open.
If you’d like to take the first step in getting your app started, get in contact and we’ll get started on those estimates.
The simple secrets to making your extended team work
This guide will touch on engaging an extended development team and what processes you need to have in place. Following that will be tips on how to bridge the gap between local and remote workers and how to keep the team working smoothly. All the information comes out of our years of experience helping clients make the most of their SoftwareSeni extended development team.
If you’re unfamiliar with the terminology, this article on the extended development team model and what you need to know might be a good start. If you’re after a quick, general summary read the FAQ on the extended development team model.
If you’re still undecided about engaging an extended team you might want to read this article on how a team extension can help you do everything you want but can’t. The information is useful for anyone looking to engage an extended development team or has an extended development team and could use some pointers. If that last one describes you, some of this information might be arriving just in time. Building a cohesive, high-performing hybrid local/extended team starts from day one, but it is an ongoing process that can always be improved.
Covid radically changed experience and expectations
At the beginning of 2019 experience with remote workers was rare. Now it’s almost universal. But there is a difference between managing a remote team member and integrating a remote team member with a local team. Software development veers between an independent and collaborative process. Your processes need to be able to support both types of working while maintaining cohesion across an extended team.
We have seen the greatest success with remote teams from start-ups and scale-ups that have a mature Agile process in place. This maturity might be due to the business having a history with Agile or its developers bringing that experience. The Agile methodology works great with remote teams. And all the developers in the SoftwareSeni extended team pool are experienced in Agile.
The burden of hiring is on us
Hiring a new developer can take months. Assembling a full team — it doesn’t bear thinking about. At SoftwareSeni we’ve already handled the time-consuming part of the process — vetting, testing and interviewing. We operate in a market where we can be selective and our in-house culture has created high retention rates. This means the developers in our extended talent pool are capable, experienced and have helped multiple clients successfully complete their projects.
For you, our hiring process and experienced developers means selecting your preferred team members, conducting confirmation interviews, and commencing onboarding can be completed in days instead of weeks.
Making it work from day 1
Having a streamlined onboarding process for your extended team members can save a lot of headaches. We supply your extended team with workspace, a development machine and all the support they need. On the software side, which is your territory, the best practices we regularly see use an automatic process to set up the tools and repositories the developers need to start working. These processes have made use of scripts, Puppet, Ansible, and docker.
The worst practice is a specialised development environment with poor documentation that takes a developer days to get up and running. Don’t make the mistake of treating onboarding as a technical test.
Provide multiple avenues for communication
Think of onboarding as the time from a developer accepting their role and being able to complete sprints independently. At this point they are familiar with your business, the code they are working on, and how your team operates.
They’re professionals. They’ll get there, but how long it takes to get there can be shortened by providing rapid feedback in the early stages. This is when they are learning their way around your codebase. A tool like Slack, with a channel monitored by a team leader for this purpose, will let them quickly get answers they need to skip over any roadblocks. Issues that require more than a few lines of chat can jump over to Zoom or Google Meet or other video conferencing with screen sharing to move rapidly to a solution.
Video conferencing, for stand-ups, code reviews, and even virtual team gatherings for social occasions, is vital for building the familiarity that bonds hybrid core and extended teams together and keeps them moving towards the common goal — your success.
The message here is to not treat your extended development team as a black box – instructions in, code out. Integrating them fully into your team is key to achieving the benefits of investing in an extended team.
What happens if the extended team isn’t perfect?
Just like any team, there is a chance issues might develop within your extended team. SoftwareSeni has fully documented processes in place to resolve these. These processes remind us that we are dealing with people, not programming machines, and provide an ethical and supportive path to a solution.
If a problem with an extended team member becomes apparent in the first two weeks of working with you, we will work with you to find a solution. Sometimes the solution is to release the team member and engage another. In this case we don’t charge you for the hours already worked.
If a problem arises after the initial two weeks, we will put more effort into finding a working solution. This will be in consultation with you and will include clearly specified milestones and dates. Our goal is always to keep you on track. In the event our shared plan does not deliver the results you need, we’ll begin a new team member selection process.
This process is explained in more detail in our Performance Management Policy document that we share with our potential clients. Get in touch if you’d like to see it.
In the end it’s about the team
In-house team or in-house plus extended development team, the collection of people still needs to be a team. Each member needs to feel a part of the team. They need to know where they fit in. They need to know their work is appreciated. They need to understand that they are part of your success. This comes from working together, overcoming challenges together, and celebrating the wins together.
It takes discipline and practice to achieve the cohesion of a purely in-house team when you move to an extended development team model. By being prepared with your onboarding and focusing on regular, responsive and consistent communication, by being inclusive, and by addressing issues as soon as they appear, an extended team can expand what you thought was possible to achieve.
If you’re ready to achieve more, contact us to start building your extended team. Team extensions are one of our core offerings. We’ve helped startups, scale-ups and SMBs punch above their weight in the marketplace with flexible, on-demand technical expertise.
How a team extension can help you do everything you want but can’tSoftwareSeni team extension services help our clients do the impossible. Projects beyond their expertise, features outside their capabilities, services exceeding their budgets.
This article is going to introduce you to the team extension model (aka extended team model), show you how other businesses are using them, and get you thinking about what you could accomplish with an extended team and how it could transform your business.
Team extension in a nutshell
An IT team extension or developer team extension is a specialised form of staff augmentation. Rather than a patchwork fulfilment of roles within a business, a team extension’s purpose is to strategically target the skills and experience you need and integrate them cleanly and efficiently into your development process.
The extended team works just like the original team. They report to the same people, they share the same goals, use the same tools, and work on the same codebase as your existing team.
Pre-Covid an extended team might have been a challenge, but now with remote work the new normal, global reliance on video calls and chat, your team has the skills and tools to work with an extended team, and working with the extended team members is now indistinguishable from your inhouse team.
Isn’t this just out-sourcing? And doesn’t that have drawbacks?
You might argue that team extension is just out-sourcing. The extended team is out-side the office.But with out-sourcing you are handing over the entire production of a product, along with any control you might have, to a third party.
With a team extension you maintain complete control. Your extended team participates in stand-ups, meetings, and planning alongside your existing developers. And unlike out-sourcing, they are dedicated solely to your project. You, or your project or product manager, decides where their time is spent, just like your in house team members.
This does require that you have the ability to manage the higher headcount and the complexities that might bring to scheduling, communications and prioritisation.
So a team extension is about getting cheap programmers?
No. It is about accessing talent. Team extension often makes use of programmers in off-shore and near-shore markets. Depending on your local market and the competition for talent, they may be the only way to access the skill sets and experience you need.
The SoftwareSeni talent base is near-shore, based in Yogyakarta, Indonesia, a national tech hub. This provides a great time zone overlap, unlike other locations. And our talent base are all developers we’ve worked with across multiple projects. Some have been with us for years.
Having access to a pool of proven developers is an incredible advantage. The biggest advantage you should care about is time. Speed of execution. There are multiple financial advantages, which we will outline later, but the time advantage is where we think the extended team model pays dividends.
The time advantage of an extended team
When you think about adding to your head count you automatically think about how much faster work will be completed and how much more quickly goals will be reached. Mostly true, though the Mythical Man Month would say temper that vision with a grain of salt. But there are even more important ways team extension gives you time advantage.
Reduced time to productivity
Time to hire can be months, particularly for in-demand skills. Between waiting for viable candidates to apply, interviews, negotiations, resignation periods, and onboarding, you can lose a big chunk of a year making a single hire. And if you’re building a team with interlocking skills the time before the team is operating at the level you need can be even longer.
Extending your team through SoftwareSeni reduces the interview process to assessing team and organisational fit. You choose the pre-vetted candidates you want to talk to. That’s it.
Less time to integrate them
After finding a developer someone on your team needs to make space for them, find them a desk, purchase and prep a computer, get their details into all the HR and payroll systems.
You don’t need to do any of that. We provide all of our programmers with the space and equipment they need to be productive from day one. All the administration is handled by us as well. For you, they are there to help you meet your goals from day one.
Shorter time-to-feature
At this point – team selection complete, new developers onboarded and ready to go – you’re already a couple of months ahead. With professional project management, your extended team will be completing more sprints, increasing the feature count delivered each cycle. Or you will be moving forward on the direction that had been walled off to you because you didn’t have or couldn’t afford the resources.
The cost advantages of team extension
The upfront cost advantages of an extended team were implied in the section above. We’re not recruiters. We don’t charge fees for placing our programmers in your team. That will save you five figures per team member.
Ongoing costs are set. You know how much you are paying for each extended team member. It’s a predictable number you can budget around.
Costs like office space, equipment and the like are zero. They are taken care of by SoftwareSeni.
Despite all this, we don’t think you should be thinking about your extended team in terms of costs, but instead in terms of earning potential. Focus on what you can achieve with a team extension and how that will impact your bottom line.
The challenges of adopting an extended team
Any rapid increase in headcount can be a management challenge. This challenge is magnified by the remote nature of the extended team and the communication hiccups that can result from a multinational team.
You will need to ensure you have project management capacity in place to handle the increased head count. For some businesses, this is the greatest risk to an extended team and the most common cause of reality not meeting expectations.
Finally, for a close-knit team it can take time to adjust to and integrate multiple new team members.
All these challenges can be overcome. We’ve seen it happen. We’ve helped it happen. That is another benefit of a SoftwareSeni extended team – you’re not in it alone. Hire an employee and their problems are your problems. Extending your team through SoftwareSeni and we are there to support you and your extended team through the challenges and onto success.
You’re never too big or too small for a team extension
We obviously can’t go into details, but we think these brief examples will help you get an idea of how an extended team can be structured and what you can achieve with one.
Site production and support
A major media organisation uses an extended team of 3 part-time developers on a dedicated sub-site. The developers are split between implementing new features and devops.
Accelerator team
A startup in the energy marketplace increased their development capacity by 30%. Eight SoftwareSeni developers are currently helping them fast-track features.
Entire tech team
A two-person startup in the real estate market with a great idea and no technical skills built their entire product using a dedicated extended team from SoftwareSeni. That team continues to add features and keep the business running smoothly.
Full operation support
Another real estate services business runs their entire business with an extended team from SoftwareSeni. 75% of the team is software development and technical support. 25% of the team provides customer support. They keep thousands of paying customers happy.
What could you achieve with an extended team?
At this point we hope your brain is ticking over with the possibilities. You have some solid insight into the advantages and disadvantages of pursuing a team extension. You can see the unlimited upside.
The next step is to talk to us. We can help you turn those possibilities into a plan and make that plan a reality.
Contact us here. We provide extended development team services and staff augmentation.
If you’re thinking you might not be able to handle an extended, check out our article on the simple secrets to making an extended team work.
Product Conception – Bringing your business idea to life with the Lean Canvas
In this article we’re going to talk about product conception. We’re going to start with a broad overview of what a viable product idea needs. Then we’ll cover the process — the steps you need to take, the information you need to uncover — to complete your product conception. We’ll use the Lean Canvas for this. The Lean Canvas is a top level summary of your idea that will serve as your blueprint as you move onto the next stage, prototyping.
Why are we qualified to talk about product conception? Experience. Since SoftwareSeni started in 2013 we have taken dozens of businesses from initial idea to launch. We know the blindspots. We know your market isn’t “everyone”. We know how to dig to the core of your idea.
That digging is what this article is about.
The difference between a Good Idea and a Bad Idea
The best ideas come from insiders. People with years of experience and a detailed knowledge of a particular market. Maybe that’s you. Perhaps you’ve seen a pain point being ignored, a gap in the market, or an even larger, more radical opportunity.
This recognition of a real world problem that is calling out to be solved is the first sign you are onto a good idea. Bad ideas tend to be solutions to problems no-one has or no-one is willing to pay to fix.
Good ideas often arrive along with a vision for how to solve the problem. This vision is the start of the product conception.
As a vision, the solution is exciting, inspiring and rich with promise. It’s all three that drive businesses forward. But at this early stage, before vision has met reality, you already need to be prepared for it to grow and change.
It’s not the best quote, but “No plan survives contact with the enemy” is the most relevant. We can paraphrase it as “No business idea survives contact with the market”. At SoftwareSeni, we find it’s the teams that can adapt as they learn more about the intersection of their idea with the market that finish with the best results.
How to explore that intersection between your idea and the potential market, what you need to do and learn, can be a mystery if you’ve never attempted it before. Luckily, there’s a framework that provides a clear guide — the Lean Canvas.
Uncovering your blindspots with the Lean Canvas
Filling out a Lean Canvas will help direct your research and your thinking. It’s not the only way to conceptualise a product, but it’s easy to implement and it’s effective.
The outcome of completing the Lean Canvas is a clear understanding of your product and the business you are going to build around it. It is the necessary input and foundation for your prototype.
Let’s run through the sections of the Lean Canvas.
Problems and Solutions
Problems are the pain points you’ve recognised. If you’re diligent you’ve already confirmed they are actual pain points your potential customers have and are willing to pay to fix.
You might be thinking there’s not much space to write these things down. That’s the plan. You want to be concise and clear. It is a communication tool as much as it is a planning tool.
Key metrics and Unique Value Proposition
How are you going to measure progress and success? If you’re a start-up or a scale-up you might be focused on growth and interested in your DAU/MAU ratio or your churn rate. Perhaps you’re also focused on optimising your funnel and you want to track your Cart Conversion ratio. Write them all down.
Your Unique Value Proposition (UVP) is why people should choose you over the market incumbents. Is your UVP viable? Is it valuable? To your users? Is it compelling? Is it new? (Is it just another way to say Unique Selling Proposition?)
High Level Concept
This is the classic “Uber for X” statement. A single, short sentence that communicates what your product is about. Is it Facebook for pets? A concierge for cosmetic surgery? Craigslist for Gamers? AirBnb for medical tourists? A marketplace for pig breeders?
You want a statement here of such clarity that whoever hears it will grasp immediately how your product will work and who will use it.
Unfair advantage
This is a factor that your competitors will find difficult or impossible to replicate. It could be that you’re first in the market. Or your team has cornered the expertise needed. Maybe it’s personal — you’ve built up a community that is eager for your product. Perhaps you have a gun team that can out-manoeuvre the competition.
The bottom line is you want something to protect you from the competition. Once your app goes public and your success becomes apparent competitors will rush in.
Channels, customer segments and early adopters
You need to know where and how you’re going to reach your users. You need to know who they are and what their story is. Key amongst your customers are the early adopters. These could be the users who are simply more inquisitive, more adventurous, or the users who are desperate for a product that will solve their problems. Knowing who they are is the first step to working out how to reach them.
Cost structure and Revenue Streams
The outs and ins of your business model. The cost structure here is of course your initial cost structure. In the beginning it can be the right thing to use strategies that don’t scale. Throwing money at street teams when you launch might be the most effective growth accelerator for you.
The Revenue Stream box is where you lay out how your product is going to earn its money. It could be sales, subscriptions, transaction fees, etc. Don’t have a revenue stream? Congratulations, if you can keep growing fast enough after you go live you might be declared a unicorn, pivot a few times, and back into an IPO via a SPAC before starting your own angel investment firm.
On a serious note, these two boxes will feed back into your Key Metrics. Make sure the relationship between them makes sense.
What it’s going to take to fill in your Lean Canvas
The key to filling out the Lean Canvas is interviewing your potential users. These initial interviews serve as a rough sample of your customer segment. The more users you talk to and the more that see the same problems you do, the more you can be sure you’re on the right track. But the truth is in the numbers. Talk to 5 potential customers and 3 agree? You might be onto something. Talk to 10 more and find no further agreement? You’re starting to get a feel for how pervasive your problem really is, or is not.
An initial online survey can help here. It’s faster than conducting 100 interviews and the Lean Methodology is all about speed. As a first step it can help you confirm interest level and even refine your market segment.
The final output – ready for prototyping
Coming out of this process, completing your Lean Canvas, your moment of inspiration has been tested, improved, focused. You had an idea and now you have a product concept you can clearly communicate to others — your team, your customers, your potential investors.
With a solid product concept you’re ready for the next stage — prototyping. Read an introduction to prototyping your app here.
Until then, if you have a product concept you want to take to the next level, get in touch. We’d love to talk about it with you.
(You can also start your lean canvas right now by clicking here.)
Agile basics for small businesses and start-upsTo understand Agile you need to understand where it came from. Building software is hard. You’re building a complex system. Bridges are complex systems, too, but they are regularly completed on time and on budget. So why does software development have a reputation unpredictable and unreliable?
The big reason is this: If you start on a bridge over a river, short of an earthquake, the other bank is still going to be there two years later when you reach it.
But in software and business, two years, even one year, is enough time for the ground to move underneath you. In two years your app might be obsolete or facing dozens of competitors. Or the underlying market has changed, your vision is outdated, and half of the software being built needs to be thrown out, another chunk needs to be updated, and your deadline is suddenly far behind the advancing market and user taste.
You end up chasing change, so busy keeping up that you never reach the finish line.
This is when Agile becomes an advantage.
Agile is not about building software as quickly as possible, it’s about releasing software as quickly as possible.
Agile and the MVP
Agile is where the Minimal Viable Product (MVP) meets Lean Business practices.
Following the MVP philosophy, your product might not be feature complete for years, but when it is developed with the Agile methodology, it will be delivering value to customers within weeks. That value will increase as the Agile team continues to incorporate feedback from users, build new features, and release them to the user base on a regular schedule with a shortened cadence.
Two weeks after launch, the search bar appears. Two weeks later users have a dedicated view of their favourite items and the search bar now has autocomplete.
By structuring development to deliver a new release every few weeks the MVP increases in value to its users, but continues to be an MVP. Because priority is given to value instead of features.
To find that value, Agile relies on User Stories.
What is a User Story?
A User Story is a high level description of what an app or web site needs to do written from the perspective of a user.
The classic format for a user story is “As an X , I want to Y, so that Z“.
Here are examples of two user stories:
“As a first time home buyer, I want to keep track of houses I’m interested in, so that I can buy my dream home.”
“As a real estate investor, I want to know average house prices, so that I can spot a bargain.”
User stories aren’t technical. They are meant to be discussion points between product owners/managers and developers. Separate to the discussion the developers devise a strategy to deliver the features that support the user story within a series of sprints.
What is a sprint?
A sprint is not a period of frantic typing and programming. It’s Agile terminology for the short block of time allocated to implementing features in an app or site.
Sprints tend to be 2 or 3 weeks long. This duration is a compromise between the challenges of software development and the drive to regularly add value to the users’ experience.
If a user story cannot be fulfilled within a single sprint it becomes an Epic. Epics take multiple sprints to complete. The challenge with Epics is maintaining that continuous addition of value to the users at the end of each sprint. It can be done. It just takes planning.
Hold up! Agile is more than User Stories and stand up meetings
“Working software over comprehensive documentation” is one of the four declarations from the original Agile Manifesto. It is not a rejection of documentation. The writers of the manifesto were all experienced programmers. They knew documentation was important.
But they created Agile at a time when the Waterfall Model was the leading methodology. In Waterfall, you plan and document everything up front. As if you were building a bridge and knew where the other side of the river is. And then your team worked methodically, step-by-step, over months and years, to implement the plan, complete the software, and release it to a market that no longer cared.
It was a methodology that sometimes saw projects spend months producing hundreds, even thousands, of pages of documentation before the first line of code was written.
Under Agile, the developers still need to know how the app is going to work, how it is meant to integrate with your business, and how your vision is to be supported.
Business rules still need to be provided, in all their detail. Wireframes need to be drawn and refined. Colours need to be specified.
Developers are in charge of implementation. You need documentation to provide the necessary details about the “what” they are implementing so they can focus on the “how”. It is one of the keys to being Agile.
Agile isn’t the solution to everything
Don’t make the mistake of looking at Agile and thinking it is a way of building software faster than normal. Agile brings responsiveness, not acceleration of software development.
That responsiveness requires experienced developers. Developers not just with a certification in Agile, but also years of experience with the technology and in delivering working software. It took years for the developers at SoftwareSeni to reach the level where they can deliver consistently. Learning Agile was a tiny part of that skill.
Responsiveness might also be what rules Agile out for you. If you’re not building software for a new market, or a market that is continually changing, traditional development models may work better and have a tighter fit with your company’s culture.
Your company’s culture might also be the thing that makes Agile the wrong solution for you. A top-down management style where decisions have to pass through multiple levels of stakeholders for sign-off is the opposite of Agile. Agile is about trusting the developers, trusting the conversations with product managers, and allowing a team to execute with minimal interruption.
If you’re already crafting the email chain in your head for feature sign-off, trying to implement an Agile process will be an exercise in frustration.
The last word on Agile
This article has given you the concepts you need to know when considering adopting an Agile methodology yourself. You hopefully have an insight into whether or not you can (or should) take advantage of it.
If you’re outsourcing your development, an Agile partner like SoftwareSeni can help you decide if Agile is appropriate. We’ll be happy to work with you, help integrate you into your own Agile team of developers, and apply this very effective development strategy to your competitive advantage. Get in touch.
How thinking like Frankenstein will help your MVPWhat stage are you at with your MVP? Because the earlier you start thinking more like a mad scientist and less like a FAANG product manager the better your MVP’s chances of success are.
At the napkin sketch stage? Excellent. Wireframing? That’s great. Clickable prototype? Still got time. Coding? You might want to hit pause while you finish this article.
V is for viability
Viable in Minimal Viable Product does not mean that your product works. You’re not going to launch a product that doesn’t work. Viable means it fulfils the business goals you set for it. It is helping to answer the questions about your customers and your market that you created it to test.
The next iteration is also going to be an MVP. So is every iteration that follows as you close in on market fit and profitability.
How fast can you iterate? And how many iterations can you afford? Enough to find that market fit?
You don’t know. No-one ever does. The best you can do is iterate as fast as you can and minimise the cost of each iteration.
Which brings us back to Frankenstein.
Focus on creating, not re-creating
Frankenstein was focused on creating life, not hands or feet.
You’re creating a product. A new product, never before seen. You don’t want to throw away time and effort re-creating the basic building blocks products are expected to have.
You want to spend all the resources you can on your unique IP, the features that give life to your product. Everything else is product hygiene.
IP vs product hygiene
You want to minimise your spend on product hygiene. Product hygiene means your product meets user expectations. It has the features they expect. Those features work as they expect. If they need to register, they can register via an email, Google, Facebook, etc. When they go to make a payment, their preferred option is available and it happens quickly and smoothly.
It is a form of visual and functional competency. Professionalism. You can also think of it as table stakes for being competitive in the market.
A big part of product hygiene is convention. Apps have been around long enough that everyone knows how they work and how they should work.
When you prototype your MVP you want to split out what parts of it are product hygiene and what parts are secret sauce.
The secret sauce is where you want to spend your effort and your money. This is your differentiating IP.
Product hygiene – you want these parts implemented as quickly and cheaply as possible.
Build or buy?
This is where the Frankenstein approach comes in. You won’t be using body parts. You will construct your competition-stomping monster out of SAAS integrations, open source components, and third party libraries.
Payments is the number one example of adding product hygiene using an SAAS. You could throw money and months at building your own payment system or simply integrate a service like Stripe.
At SoftwareSeni we draw the line between buy and build every day. And every day more features fall on the buy side.
The buy side includes free and open source software (FOSS). It has ‘free’ in its name, but integrating FOSS and maintaining it still costs money.
Some of the common services we integrate so you don’t overspend on features that provide product hygiene but don’t contribute to your competitive advantage are:
- Membership/User registration
- Search/Elastic Search
- Email sending (using Mandrill, Sendgrid and others)
- Ecommerce/Payments (using Stripe, Paypal, eWay and others)
- CMS/Blogs (using WordPress)
Your moat, the features that make you stand out in the market and give you an edge, will need to be built by you and your team.
Building your moat
In the marketplace moats are built out of code. It can’t be avoided. Just ask Uber. Eleven years after launch, they still haven’t turned a profit, there are numerous competitors, and every local taxi company has a ride hailing app.
That’s a simplistic take, but it has a nugget of truth. If your entire feature set can be built from integrations and libraries you want to revisit your strategy and your idea.
Your moat will be built upon a framework. It might be WordPress, React, Ruby or Laravel. Your choice will depend on your own experience and your inhouse developers’ experience (if you have any). At SoftwareSeni we work across all the major application frameworks.
Your moat will be your entire UX and the business rules behind it. This is where you want to direct as many resources as you can.
Integrating SAAS and FOSS doesn’t come free, but they represent hundreds of thousands of lines of code you don’t have to pay for or wait to be written. They also represent code you don’t have to maintain. In general, you can estimate that the ongoing maintenance and support of any code written for you will cost about 20% of the development cost per year. It’s just like maintaining machinery in a factory. Pieces start to rust and eventually stop working.
Bolting together your first MVP, and the next
Hopefully this article has opened your eyes to a different approach to building your MVP. Thinking like Frankenstein, building with off-the-shelf parts whenever you can, will accelerate your path towards your MVP. It will shorten your iteration times and increase the number of iterations you can squeeze out of your budget.
Doing it well requires a wide knowledge of the libraries and services available and how they fit together. This is part of SoftwareSeni’s expertise. Collaborating with you to break down your product idea into the optimum combination of buy and build is a key part of our lean strategy.
If you’re at the sketch stage or ready to code, take a moment to talk to us. We’ll help you get more V into your MVP.